Вопрос неоднозначный. Программисты бывают разные и причины слиться у них тоже разные. За свою карьеру я успел побывать в шкуре активного программиста (ну это тот, кто может кодить по 14 часов в день и больше, просто потому, что нравится) и не понаслышке знаю причины потерь интереса к проекту вплоть до его полного отторжения.
Сейчас я сам привлекаю программистов к проектам и могу наблюдать, как бойцы выбывают из строя уже глазами менеджера. Так что постараюсь описать картину всеобъемлюще.
Итак, приступим-с к причинам.
Неправильно оценил объем работы
Пожалуй, это самая распространенная проблема, по которой возникают бесконечные проволочки и пропажа всякой мотивации к дальнейшей работе. Кстати, ваше четкое ТЗ вовсе не гарант того, что программист, даже опытный, не попадется в эту ловушку, а вместе с ним и вы. Тупик возникает, когда выделенный бюджет исчерпан, а проект все еще не работает. Звоночком к такой ситуации может служить отсутствие каких-либо уточняющих вопросов со стороны программиста перед началом работ или явная их недостаточность для воссоздания образа нужного вам результата. Другим звоночком служит то, что программист бьет себя в грудь и говорит, что «тыщу раз такое делал». Если два в одном – вообще ахтунг. Когда внутреннее субъективное мерило затраченных на работу усилий скажет программисту «хватит», то заставить его довести дело до конца будет очень трудно.
Незакрытые (или вновь открытые) обязательства по другим проектам
Возможные варианты: упал сервер на другом проекте – надо срочно поднимать. Перегрелась и рухнула БД, встали продажи и клиент давит, а терять его неохота. Короче, что-то и где-то сломалось, горит или скоро развалится. В этом случае на ваши обязательства временно забивают, затыкая дыры там, кто больше платит или с кем прочнее связи. Вы подождете. Особенно, если у вас проект меньшего масштаба или бюджета. Ну, или вы просто не умеете требовать результат так, как те, у кого «горит».
«Нежный» программист
Это я уже пишу как менеджер проектов. Сами программисты этот пункт никогда не признают причиной своих сливов. Виной тому недостаток предложений на рынке и его общая перегретость, где в погоне за лояльностью программистам платят оклады просто за их присутствие в офисе. Почему-то также повелось, что если программисту дать хороший стул, шведский стол, обеспечить дневной сон на работе, ДМС, возможность брать несколько оплачиваемых выходных в неделю и зарплату «в стопицот тыщ» рублей, то он будет работать лучше. Часто такой подход рождает программистов-одуванчиков, которые забывают, что работа, в первую очередь, – это обмен их знаний и навыков на условные рубли при том, что их деятельность рождает приемлемый результат. Скажем честно, в других отраслях такого массового пестования персонала, как в ИТ на сегодняшний день нет. Если такой неженка однажды попадется вам, то спросив его о результате, – а бурную деятельность он изображать умеет! – вы можете нарваться на непонимание и позицию «ой, все, я устал». И он искренне вас не поймет, он же работает «не трогайте меня». Позиция «закрыться и пропасть» супротив «напрячься и сделать»– то, что они выбирают, когда с них требуют показать плоды своей работы, если их нет.
Низкий уровень личной ответственности и социальных навыков
Отчасти это подвид нежного программиста, но не всегда. Если в случае с нежными программистами, они, во многом, бывают очень даже подкованными – и говорить на одном языке с заказчиком могут, и презентацию сделают, и ответственностью обладают (ну в том, что работу делают), то эти кадры могут даже не работать, если посчитают свои личные дела превыше вашего проекта. Поехать собаке за кормом в рабочее время? – легко. Он даже не постесняется сказать вам это вслух! Или «у ребенка утренник в саду» – ну и что, что уже три часа дня, а его все нет на связи? – проект, ведь, подождет. Бывает, так, что у этих же ребят плохо развиты навыки уточнения задачи – ему проще решить что-то за вас, чем позвонить (не дай бог – подойти!) и прояснить вопрос. При этом его решение может усложнить ваш проект (и исчерпать бюджет), когда это не нужно. И вы об этом даже не узнаете, если не будете сами контроллить такие моменты. Позже он сам обвинит вас в очень сложных деталях, о которых вы умолчали, а он их героически преодолевал (но не преодолел и забил).
Неправильная организация работы
Ну, хватит все валить на программеров:) Наконец, можно поругаться и на тупых заказчиков, менеджеров и прочих «воротничков» в образе управленцев и всяких там прОдуктов. Да, к сожалению, их подходы часто бесят нормальных ребят, готовых честно и плодотворно работать на создание качественного продукта. К неправильной организации я отношу: избыточный контроль, недостаточный уровень коммуникации – программисту просто некому задать вопрос или ответственному за проект всегда некогда на него ответить. Постоянные изменения ТЗ, доработки и допилки, которых не было заявлено изначально, при неизменном бюджете. Странные решения, влияющие на логику проекта так, что надо переписывать все заново. Смена ответственных лиц. В защиту заказчиков стоит сказать, что иногда программисту требуется переписывать все заново, по причине его недостаточной квалификации или неучтенных требованиях в начале работы над задачей.
Написав это, я перечитал пост еще раз и подумал, не забыл ли чего? Думаю, что забыл. Ведь случаев из практики у меня настолько много, что трудно их все припомнить. Когда вспомню что-то еще – обязательно напишу, но думаю, что самые массовые случаи слива я все же захватил!
Подписывайся на канал и следи за обновлениями! Качественных и крутых тебе проектов и восхитительных результатов!
