Из всех монстров, которыми наполнены кошмары нашего фольклора, самыми страшными являются оборотни, поскольку нас пугает неожиданное превращение того, что нам хорошо знакомо, в нечто ужасное. Мы ищем серебряные пули, которые могли бы волшебным образом уложить оборотней наповал.
Хорошо знакомый программный проект напоминает таких оборотней (по крайней мере, в представлении менеджеров, не являющихся техническими специалистами) тем, что, будучи простым и невинным на вид, он может стать чудищем проваленных графиков работы, раздувшихся бюджетов и неработающих продуктов.
"Мифический человеко-месяц", Ф.Брукс
Хочу поделиться обобщением историй от заказчиков IT-проектов, с которыми мне удалось пообщаться и поработать. Эти истории очень похожи, а значит на их примере можно научиться, сделав нужные выводы.
Так получается, что в мою компанию приходят проекты со сложной историей: прошел первый deadline, прошел второй, релиза нет, инвесторы в отчаянии, проект готовы выкинуть и признать провальным. Мы вытащили не один такой проект и сделали успешный релиз.
История провальных проектов
Проблемы с проектами появляются в разного размера компаниях, на разных платформах разработки или в разных странах. История одинаково повторяется в России, США и Англии. Повторяется почти в деталях. Анализируя историю таких проектов, я заметил тенденцию, выделил общую суть.
Сцена первая — Обнадеживающая
Когда проект только начинается, работа над ним кипит, заказчик очень быстро получает много новых функций. Надо добавить регистрацию — пожалуйста. Ленту новостей — пожалуйста. Разделение на роли — без проблем. Прохождение документов по основной ветке бизнес-процесса — очень быстро.
Компоненты системы почти не связаны друг с другом. Система растет высокими темпами, рост стабилен. При этом сложность увеличивается линейно, пропорционально количеству добавленных компонентов.
Первый этап самый простой для разработчиков. Для него не требуются сильные инженерные навыки.
На этом этапе заказчик счастлив. Он видит, что задачи реализуются быстро, возможно быстрее плана, новые функции льются рекой.
Этот этап счастливого неведения может длиться довольно долго. История знает случаи, когда команды работают в режиме "только добавление" до полугода.
Сцена вторая — Разочаровывающая
Начались изменения в первоначальных требованиях. Например, поменялся бизнес или пришли конкуренты или заказчик увидел новые пути развития. И оказалось, что системе не готова к изменениям. Добавлять новое не тоже самое, что изменять уже созданное. Обнаруживается, что одна часть системы была сделана недостаточно гибко, в другой код был хрупкий и при изменении обнаруживается много ошибок. Теперь заказчику приходится ждать значительное время, когда разработчики внесут изменения.
Меняется логика регистрации, добавлены регистрации через соц. сети, регистрации через внутренние сервисы компании, через промо-акции со сторонних сайтов партнеров...
При изменении компонентов система ломается в неожиданных местах, появляются сложные связи между разными частями системы. Заливка новых версий становится всё сложнее и еще хорошо, если кто-то позаботился об автоматической интеграции и разворачивании новых версий. Обнаруживается дублирование в коде, но времени на исправление особо нет, заказчик и так переходит в категорию недовольных.
Заказчик, который просит "всего лишь добавить кнопку" не понимает, почему это занимает 2 недели. Раньше за две недели он получал несколько новых функций, а теперь небольшие изменения требуют значительных затрат. После релизов выявляются проблемы в уже отлаженных частях системы, т.е. в уже оплаченных частях системы.
Сцена третья — Провальная
Заказчик недоволен, он требует предыдущих скоростей. Он требует, как минимум, чтобы работало то, что уже было в рабочем состоянии.
Дальше два варианта развития событий:
- Команда осознает, что она не компетентна развивать проект. Она просто "сливается" и идет за следующим проектом. Заказчик остается с кучей плохого кода и горящими сроками.
- Команда не осознает своей некомпетентности, тогда паутина кода вьется до момента, пока кто-то не скажет заветную фразу: "Давайте всё выкинем и перепишем". Что это значит для заказчика? В лучшем случае потеря денег и времени, в худшем случае потеря бизнеса.
Рисуем красивые фасады
Написание таких проектов можно назвать обманом заказчика. Осознанным или неозознанным, но обманом. Вы наверняка видели в своем городе дома, на которые вместо ремонта распечатывают баннер:
Наступает момент, когда распечатку убирают и оказывается, что внутри развалившийся фасад. Тоже самое происходит и с проектами. Заказчик узнает реальную ситуацию, когда приходит ко мне, приносит проект, просит разобраться в чем дело. Он говорит: "Мы же полгода делали, все было так быстро, мы уже были готовы к релизу и тут раз, ничего не работает". Конечно не работает, собственно это и не работало никогда, увы, оно только делало вид.
Реальные случаи таких "фасадов":
- Проект работает, когда им пользуются одновременно не более 10 человек. На демо всё было отлично, но вот в реальности сервер падал под "нагрузкой". Есть практика нагрузочного тестирования, но кто этим занимался?
- Программа запускается только на одной операционной системе, грузит ее на 100% и обычно падает с BSOD. Заказчика убедили, что иначе никак.
- "Всё готово", — говорит заказчик — "надо только добавить редактирование ленты новостей и управлять фильтрацией новостей. На главной странице их всего 5, а надо добавить несколько свежих". Заглядываем в код, а там все новости в статичных HTML-файлах без бизнес-логики, как и контрол их фильтрации.
- Один проект для B2B сектора был уже запущен и отлично работал. У руководства на него были большие планы, но первое же изменение заставило переписать очень много. Дело в том, что в нем было очень-очень-очень много дублирования в коде. Одно бизнес-правило могло быть записано в 5-6 частях системы. Быстрый рост сменился стагнацией и привел к закрытию проекта.
Разработчики научились делать эмитацию работы, вместо реальной результативной работы. Эффективные менеджеры научились убеждать заказчиков, что текущая ситуация на проекте — это норма, что IT-рынок может работать только так и никак иначе.
Инженерная гордость
Такие проекты напоминают самообман разработчиков. Они уверены, что лучше сделать невозможно. Создатели "фасадых" проектов говорят заказчику: "Мы построили масштабируемую систему, она может хорошо расширяться под любой нагрузкой". Надо понимать, что ни одни действительно опытный разработчик так не скажет. Он сделает множество оговорок про реальную масштабируемость, загонит ее в рамки ограничений и опишет возможные риски.
Заявления о надежности в 146% характерны для программистов, которые находятся в квадрате неосознанной некомпетентности. Не смотрите на количество отработанных лет на должности программиста (кто-то считает это показателем опыта), от них ничего не зависит. Плохо, когда такие "ведущие" программисты имеют дар убеждения заказчика или являются тех. лидами с его стороны, потому что заказчик остается совсем один в этой неравной битве за истину. В таки ситуациях меня зовут устраивать публичные слушания.
Инструмент для заказчиков
Я уверен, что сценарий провала можно прервать. Лучше всего сделать это в самом начале на этапе выбора исполнителей. Проблема в том, что при данном уровне сертификации и лицензирования в нашей отрасли почти невозможно сравнить IT-компании. Трудно сравнить даже двух разработчиков.
Самая реальная возможность спасти проект — понять, что он идет в пропасть. Есть небольшой процент заказчиков, которые могут заглянуть в исходный код и понять хороший он или плохой. Но практически нет заказчиков, которые могли бы оценить архитектуру, ограничения и гибкость созданного решения.
Кто-то делает ставку на эффективных менеджеров, но без сильных инженеров не выйдет хороший IT-продукт. Управление в проекте тоже важно, но код первичен. Хорошая команда программистов с плохим менеджером может сделать работающий проект. А вот у отличного менеджера с плохой командой просто нет шансов.
Я периодически занимался анализом проектов, но это не было моей постоянной работой. Сейчас я хочу брать больше проектов на анализ, я верю, что спасти можно многие проекты, идущие в пропасть.
Продолжение: Работа с унаследованным кодом: Риски, анализ проекта и стратегии работы
Ссылки
Статья интересная, но оставляет некоторое ощущение незавершенности :)
ОтветитьУдалитьОк, проекты вытаскивать можно. Круто! Но как именно это сделать? Что важно на этом этапе, а чем можно пренебречь? Было бы здорово увидеть описание того, как команда выводит проект из тупика. Надеюсь, это не является секретом. Может быть, хватило бы даже двух-трёх показательных примеров.
Интересная статья.
ОтветитьУдалитьНо отчасти мне кажется проблема в другом, в психологии.
Заказчики - бизнесовые ребята, а it-шники другие ребята, привыкшие быть правильными, честными и умными.
А бизнесовым ребятам абсолютно параллельно на технологии, на архитектуру и тд, бизнес работает, приносит деньги, хочется чтобы еще больше приносил. Придумывает как все это будет выглядеть, находит ребят, чтобы сделать. Эти ребята и он разговаривают на совсем разных языках. Как правило он доминантнее и может давить, в итоге как правило it-шники проигрывают и в вопросах обсуждения цены и в вопросах сроков. А потом уже получается как получается.
А как нужно выстроить систему:
Бизнесовый чувачек - доминант
it-консультант - доминант и умник
it-шники - умники
А так зачастую разговор глухого и слепого.
Спасибо. Дело в том, что я ее почти в 2 раза сократил, вынеся другие мысли в следующие статьи. Когда они у меня в голове уложатся, я их опубликую.
ОтветитьУдалитьВы задали правильные вопросы, ответив на которые можно стать доктором наук как минимум :) Я выберу примеры, не попадающие под NDA или изменю их до неузнаваемости, чтобы описать как этот процесс проходит.
Одна из ключевых частей - найти того, кто не побоится сказать, что король уже давно голый и с этим нужно что-то делать. Заказчики упертые, до последнего не хотят признавать, что команда ведет проект в никуда. Т.е. нужен аналитик внутри компании или сторонний. Аналитик, который может разобраться в исходном коде и архитектуре, а не бизнес-аналитик, который сумеет нарисовать много красивых схем.
Когда мне дают проект на анализ, я для начала просто смотрю код. Хватает 1-2 часа, чтобы понять в чем проблема и куда двигаться дальше. Последний проект, который я видел состоял из классов 3х типов: контроллер, менеджер, хелпер. Команда уже слилась на тот момент и нужно было сделать релиз за них. Заказчика сразу предупредили, что пользователи будут недовольны релизом, т.к. код работает в определенных благоприятных условиях и не работает в других случаях :) Началась работа по рефакторингу, новые части писались уже по-новому. Работа тяжелая и не самая веселая, напоминает хождение по минному полю. За 2 недели успели сделать необходимое и релиз состоялся. В этом заслуга правильного анализа и прямых рук программистов, которые всё исправили.
С одной стороны да, но даже если на них давят и сроки они ставят неверные, то кто заставляет их писать ужасный код? Только не надо говорить, что при давлении по срокам приходится писать плохой код. Способность писать хороший/плохой код зависит только от разработчиков и никак не зависит от сроков.
ОтветитьУдалитьПонятно, что если времени вагон, то код будет идеальным у хороших программистов. Но так же понятно, что в этих же условиях у плохих программистов код будет ужасным. Как говорится не могут 1000 обезьян написать Войну и мир. Конечно есть шанс, но он минимален.
Посмотрите пожалуйста на 8-й слайд http://www.slideshare.net/AlexanderByndyu/ss-25692860
Я уверен, что у разработчиков есть определенный предел. Его можно повышать путем постоянных тренеровок, но он есть.
Александр, в описанных случаях проектов выделялась роль Архитектора?
ОтветитьУдалитьНа самом деле нет корреляции между присутствием формального Архитектора и качеством системы. Тут весь вопрос в компетенции самого Архитектора. Я видел ведущий разработчиков и архитекторов, которым по 22 года и у них за плечами год работы над более-менее серьезными проектами. Конечно бывают уникальные люди с уникальными навыками, но это редкость.
ОтветитьУдалитьЕще на счет архитекторов и ведущих разработчиков. Нет какого-то общего критерия, по которому можно разделить разработчиков на ведущих и архитекторов. Урове разработчика определяется на уровне компании. В одной компании программист ведущий, в другой даже на middle не тянет. Я думаю встречали такое?
ОтветитьУдалитьЭто понятно, но доводилось наблюдал случаи, когда и не самые плохие разработчики создавали систему, не заморачиваясь.
ОтветитьУдалитьВо-первых, когда менеджмент "давит" сроками, то волей-неволей переключаешься в режим наращивания технического долга. Хорошо еще если по этому поводу что-то остается в бэклоге.
Однако самый ад, если разработчиков оценивают только по числу закрытых тикетов без учета качества кода. На фоне таких "проворных" разрабов те, кто старается писать правильно практически со 100% гарантией в начале проекта работают заметно медленней. Если проект долгоиграющий, то "успешных" могут повысить, перевести на новый проект, а оставшиеся, разибраясь с костылями и велосипедами, станут еще медленнее с вытекающим отношением руководства.
Разумеется, так я же не зря написал именно о роли архитектора, а не о должности. Так сказать для явного обозначения режима разработки: "остановись, глубоко вдохни и подумай"
ОтветитьУдалить> Хорошо еще если по этому поводу что-то остается в бэклоге
ОтветитьУдалитьБыло время мы рисовали костыли на достке за каждый костыль в коде :)
> если разработчиков оценивают только по числу закрытых тикетов без учета качества кода
Это всё происки Эффективных Менеджеров, не будем о грустном.
Будем называть это "войти в режим Архитектора" :)
ОтветитьУдалитьБольше похоже на PR статью и рассказу насколько хорошая у вас компания. К этому скатились многие последние статьи, пользы минимум, а линия самовосхищения пронизывает каждую. Ссылки внутри статьи на слабо связанные вещи, больше похоже на сео. Возможно, мне кажется.
ОтветитьУдалитьОписанный сценарий очевиден и касается любого бизнеса и стартапа. Какой вы для себя видите смысл своих статей?
Хорошая статья. Я сейчас работаю именно в таком проекте и в такой ситуации. Статья грустна, но помогает составить структуру разговора с менеджером. Хорошо бы увидеть продолжение.
ОтветитьУдалить(Рассказы, что кто-то пиариться появляются в любом обсуждении и относятся к белому шуму)
Жаль, что вам так показалось. Я хотел показать текущую ситуацию с разработкой ПО. Ее явно нужно менять, чтобы происходили изменения об этом нужно говорить и обсуждать.
ОтветитьУдалитьВ статье 4 ссылки: на описание моих консультаций, на статью с хабра про матрицу компетентности, про технические долги, про историю как компания переходила на DDD. Не уверен, что это как-то влияет на СЕО и по-моему они указаны в тему.
Да, спасибо. Самый главный козырь в разраговоре с менеджером я описал http://blog.byndyu.ru/2008/12/blog-post.html в разделе "Почему руководители это допускают?". Успехов в изменении ситуации на вашем проекте :)
ОтветитьУдалитьhttp://www.it-cortex.com/Stat_Failure_Cause.htm
ОтветитьУдалитьИсследования еще с 1995 года, и в общем целом, всё там же и остается.
Это нельзя поменять, всегда есть хорошие разработчики, и всегда будут плохие.
Как и компании, которые делают хорошо и которые делают плохо.
Это очень показательный пример. Возможно наша индустрия ничему не учится. Прошло 20 лет, а ситуация не изменилась.
ОтветитьУдалитьВы думает так будет всегда или есть выход?
На самом деле мне просто жаль, что раньше были хорошие технические статьи и участие в подкастах.
ОтветитьУдалитьА сейчас статьи скатились до менеджерских и весьма банальных, и все презентации о том же.
Мое убеждение, что те кто хотят и могут понять данную проблематику, понимают её итак, а тем кто не может, презентации не помогут.
Я думаю корнями это уходит в человеческую сущность. И одинаковая картина во всех индустриях.
ОтветитьУдалитьВ нашей еще не все так плохо, но просто из-за того, что профессия обсулавливает совсем небольшой перекос в контингенте.
Находясь только в нашей индустрии, возможно, относительно себя кажется, что всё плохо.
Хотя в целом по палате, картина выглядит лучше.
Да, я понимаю. Для меня сейчас чисто технические статьи не представляют особый интерес. Основные виды деятельности сейчас: развитие своей компании и преподавание в ВУЗе.
ОтветитьУдалитьНа счет банальных или небанальных вещей приведу пример. Я был на конференеции, где меня попросили рассказать про DDD, это было несколько месяцев назад. Я думал, что тема на сколько изучена со всех сторон, что добавить уже нечего. Оказалось, что почти никто не знал, например, в чем суть persistence ignorance и как это работает в реальных проектах. Что может быть проще? Заглянуть в первые ссылки в поисковике по этой теме и вроде всё понятно.
Я рад, что есть тусовка, где такие "банальные" вещи понятны. Но стоит сделать шаг в сторону и там бездонное море непонимания.
Поэтому сейчас, кодга у меня есть время, то я стараюсь вести пары в ВУЗе и писать про основы.
В любом случае спасибо за обратную связь, мне самому нравятся технические темы, постараюсь на них выделять время. Например, недавно писал про SignalR и его применение в реальных проектах http://blog.byndyu.ru/2013/08/signalr-net.html. Может посоветуете, что стоит рассмотреть? Что будет не банально и интересно с технической точки зрения?
Моё текущее виденье, в том что не стоит далеко уходить от технически серьёзных тем. Это реально упражняет мозг, и составляет реальную квалификацию в том числе для управления компанией. Возможно ваши успешные проекты связаны именно с техническими корнями менеджера.
ОтветитьУдалитьВозможно, чем дальше уйдете в управление, тем больше компания скатится к проблемам которые вы описываете.
Технические руководители ниже по иерархии тоже ориентируются на руководителя.
"Но стоит сделать шаг в сторону и там бездонное море непонимания."
А с какой целью вы пытаетесь это бездонное море непонимание осушить? Грубо говоря вы добавили статью, которая будет среди упомянутых в поиске, которую точно так же не поймут. Вас читают скорее всего люди, у которых эти вещи относительно "банальны" и если не будет вашей статьи они просто прочитают другую и её поймут.
Я подозреваю, что люди которые не понимают этих вещей не читают ваш блог :)
Соотвественно было бы здорово, если бы вы писали не простые вещи для масс(что есть неблагодарное занятие).
А что-то сложное и интересное, чтобы читающие вас совершали усилие в осознании.
Мне кажется чтобы развить индустрию, надо не общий уровень массы поднимать, что только хуже для вашего бизнеса, а наоборот попытаться идти на острие технических проблем, инновации и т.д.
Да, я снова с вами согласен. Но опять же хочу писать о текущем положении дел.
ОтветитьУдалитьЭту статью, например, я написал, когда месяц назад мне дали очередной проект с кучей плохого кода, исчезнувшей командой и горящими сроками.
Я не знаю как еще бороться с такими программистами, кроме как писать об этих проблемах. Уверен, что кто-то найдет полезное в моих заметках и свернет с неправильного пути или в будущем остановится и просто не пойдет по этому пути.
Есть много новых тем, которые я сам использую, связанных с NoSQL, поисковыми движками, очередями и облачными сервисами. Никуда от программирования я не ушел и не уйду, это же мое любимое занятие :) Мне особенно нравится уход от стандартных компонентов в сторону Open Source.
Хорошо, с нетерпением жду продолжения темы
ОтветитьУдалитьАлександр, ты видимо имел в виду другую ссылку о матрице компетентности - http://habrahabr.ru/company/stratoplan/blog/198870/, вместо http://habrahabr.ru/company/stratoplan/blog/201242/
ОтветитьУдалитьТочно, спасибо поправил :)
ОтветитьУдалитьАбсолютно согласен с Алексеем. Совершенно бессмысленно пытаться научить программистов быть хорошими программистами, не подавая свой пример. Как говорится, хочешь изменить мир, начни менять его с себя. Пиши о том, что может оказаться действительно полезным для тех людей, которые хотят стать хорошими программистами и не теряй свою квалификацию. Все кому надо - подтянуться и поймут. Я иногда встречаю статьи у людей, где в одной строке содержится ультраконцентрированая мысль. И это моя проблема, чтобы ее понять, я должен прочитать смежный материал по теме. Коротко говоря, если есть своя компания и наполнение блога материалом в помощь - это очень хорошо, но данный блог все-таки изначально имел дух "качества кода", а превратился в коммерс и саморекламу.Ну, это мое мнение, прошу извинить, Александр :)
ОтветитьУдалитьЯ уже понял эту мысль. Блоги делить изначально не хотел. В любом случае мысли про IT-индустрию и образование куда-то писать надо.
ОтветитьУдалитьУ тебя было отличное начало темы - шаблоны интеграции. В принципе архитектура SOA очень интересна, особенно практическая сторона вопросы. Но поскольку, как я понимаю, опыта на этом поприще мало, она заглохла.
ОтветитьУдалитьКстати, чаще всего в больших компаниях разработки есть QA, который собственно занимается оценкой состояния проекта в том числе, с привлечением как внутренних групп аудита (смежные проекты), так и внешних специалистов за дополнительные деньги. Т.е. та проблема, что описана здесь - стандартный случай для заказчиков с одним исполнителем. Те, кто подумал о рисках, заложил в проект деньги на сторонний аудит. Это уже нормальная практика. По сути некий глобальный Code review :) Что касается архитектуры, то она может закладываться изначально также при совместном участии высококвалифицированных программистов из разных сред, а затем передается рабочей группе. В целом уровень компетенции IT-директора в компании справляется с этими орг. задачами, а затем делегирует PM и остальным.
ОтветитьУдалитьНет, Олег, я их напишу, тема не заглохла. У меня уже лежат черновики этих статей. Просто месяц назад дочь родилась, вот и вся причина :) Там довольно много работы, опять же не хочется повторять то, что уже многие знают, а хочется найти и выявить интересные приемы.
ОтветитьУдалитьЗа такого QA можно многое отдать, серьезно. Видимо их не очень много существует в доступности для типичных заказчиков.
ОтветитьУдалитьЭто Событие! Поздравляю, Саша. Будем ждать новых статей :)
ОтветитьУдалитьТут скорее вопрос в подходе, нежели конкретных личностях. Такая альтернативная команда, по желанию заказчика, может образоваться, если ему кто-то об этом подскажет. Другой вопрос, что недобросовестные исполнители не предлагают проводить сторонний code review, поэтому остается уповать на сообразительность заказчика в части описания и оценки рисков проекта.
ОтветитьУдалитьЯ вообще за то, чтобы заказчики IT-проектов тоже обучались. Часть про анализ провала и способы его избежать должны будут включить в обязательную программу.
ОтветитьУдалитьЗнаю как минимум одного человека, который нашел себя в роли соединения бизнеса и IT. Умеет переводить в обе стороны.
ИБД во все поля!
ОтветитьУдалить"Хорошая команда программистов с плохим менеджером может сделать работающий проект". Вот не соглашусь. Приведу пример. Менеджер лет 10 назад кодил во всю на чистом Asp, даже успешно кодил. Еще менеджер знает скуль и считает, что вся логика там должна быть. Еще менеджер у нас не простой, а владелец фирмы, а это означает, что в любой момент он может взять любого программиста и посадить на свой проект, оторвав, соответственно, этого программиста от текущих задач. К несчастью, этот менеджер считает себя гениальным архитектором, при этом для него слова solid, gof, grasp, EAA - пустой звук. И этот гореархитектор - менеджер считает, что только он способен выбрать инструменты разработки и используемые фреймворки. А хороший фреймворк для этого менеджера тот, где все можно мышкой настроить. И тут начинается самое ужасное. Мышкой не все настраивается, документация по фреймворку слабая, багов в нем куча и тд и тп. Ну надо сказать, что проект пока живет, но это скорее вопреки. Хотя первые звоночки конца есть. Постоянные жалобы пользователей на дикие тормоза в системе, работа программистов месяц без выходных. Печаль вообщем. Вот что посоветуете в этом случае???
ОтветитьУдалитьВ вашем случае менеджер забирает себе довольно много ответственности и решает за команду. В этом случае шансы команды понижаются.
ОтветитьУдалитьА что уже пробовали? Вскрывали проблему? Какая была реакция?
Спасибо за ответ. Про излишнюю ответственность мы тоже рассуждали у себя в команде. Но вот как ее победить? Проблему вскрывали. Реакция полностью негативная. Тут самая суть проблемы, наверно, в том, что этот проект для шефа как игрушка. Он ему нужен, чтоб самоутвердиться в качестве архитектора и системного аналитика в одном лице. По этой причине, мне кажется, шеф никого слушать не хочет. Проект этот денег не приносит, живет за счет другого проекта, будет ли приносить - тоже непонятно. Со слов шефа - это проект-развитие, задел на будущее. Если честно, бог с ним, с этим проектом. Плохо то, что с нормального денежного проекта программистов снимают на этот любимый шефом проект. Ну надо еще сказать, что на этом проекте мы попробовали scrum. Не получилось. Возможно из-за недостатка опыта, но больше из-за шефа, который всегда вне каких-либо правил. Я, конечно, понимаю, что получить ответ на вопрос "как нам действовать, чтобы наступило счастье?" нереально. Но, может быть, вы натолкнете на правильное решение каким-нибудь советом.
ОтветитьУдалитьЗа этот год у меня было 2 подобных проекта, в обоих случаях удалось победить команде, т.е. нам. Случаи не идентичные вашим, главным отличие было то, что над неправильным менеджером стоял более адекватный руководитель.
ОтветитьУдалитьПервый проект чуть не провалился из-за тех. лида со стороны заказчика. По всем признакам проект дошел до момента, когда его можно было выкидывать, но руководитель этого тех. лида вовремя распознал проблему и сделал хорошую замену.
Во втором проекте над неправильным менеджером были хорошие тех. специалисты, которые могли вовремя его остановить. Мы с ними подружились и за счет этого удалось найти баланс.
Возможно для вашего руководителя есть какой-то авторитет, которого он послушает? Если есть, то можете ли вы объяснить всё ему?
Ваш случай был у меня только один раз, когда проект идет для самоутверждения менеджера. Закончилось всё расформированием команды и признанием проекта провальным.
Если вы действительно в явном виде показали проблемы на проекте и ваш руководитель действительно вас услышал, после чего всё равно не принимает меры, то вам надо понять свой интерес в это проекте. Возможно он приносит вам деньги, возможно вы на нем развиваетесь, возможно еще что-то. Если лично для вас на нем интереса нет, то нет смысла своим временем и силами спасать тонущий корабль.
Спасибо. Очень интересно. Надо подумать над вашими словами...
ОтветитьУдалитьНаписал продолжение http://blog.byndyu.ru/2014/01/blog-post_8.html
ОтветитьУдалитьЧеловека, который на проблему указал, ОЧЕНЬ не хотят слушать. Особенно, когда разработчик говорит, что на проекте есть серьезные проблемы, а его тимлид/ПМ закрывает на это глаза и говорит "Иди работай, у нас плотный график". Что очень печально :(
ОтветитьУдалитьЗадача сделать клиента довольным, а ему плевать сколько оверхедов я написал.
ОтветитьУдалитьСейчас на день больше, потом на месяц быстрей.