Часть 1

Решили как-то предприниматели ИТ-фирму организовать. Офис открыли, дорогим оборудованием обставили, всё по-модному и современному. Тут тебе и чай с печеньками, и комнаты отдыха, и психолог молодая и красивая. Не фирма, а заглядение.

Нашли заказчика — и появился у них новый проект. Чтобы его реализовать, решили нанять одного программиста, такого, чтоб потолковее да по-покладистее, и платить ему решили побольше. В помощь ему взяли дешёвого менеджера проектов. От него требовалось, чтобы выглядел прилично и любую прихоть заказчика выполнял.

И вот нашли менеджера и программиста. Программист — весь такой «семь пядей во лбу», рвётся в бой и готов писать хоть сутками. Менеджер — приветливый, дружелюбный и амбициозный. Одна только небольшая проблема — в программировании он полный ноль. Настолько ноль, что когда его спрашиваешь: «Что такое метод пузырька?» — он в ответ загадочно улыбается, достаёт стакан и пол-литра.

И вот начинаются рабочие будни. На любое совещание менеджер берёт с собой программиста. Надо же как-то задачи ставить, а разбираться в том, как и что писать — это не его забота. Его дело — «проект к успеху двигать». Программист же и по совещаниям бегает, и работу работает. Работы становится всё больше и больше, количество совещаний и их длительность тоже постоянно увеличиваются. Чтобы всё успеть, приходится писать в спешке. Местами уже не до идеального кода.

Заказчику, конечно же, промежуточные результаты не показывают. Зачем ему знать внутреннюю кухню? Вдруг заподозрит чего или разочаруется. Как итог, на первом релизе получают кучу замечаний, недовольного заказчика, и менеджер обещает всё переделать, и, конечно же, за счёт фирмы, в которой он работает. Они ведь сделали не то, что он ожидал. В итоге программист работает круглые сутки, чтобы всё исправить, а менеджер его ещё и дёргает по нескольку раз на день, а то вдруг он опять «дров наломает». Худо ли, бедно, всё доделывают-переделывают и показывают заказчику. Он недоволен, но так и быть запускает проект у себя и продолжает оплачивать дальнейшую разработку. А так как объём работ увеличивается и хочется, чтобы качество было получше, он соглашается увеличить финансирование.

Фирма, видя такой прирост денег, решает улучшить ситуацию на проекте. Нанимает дополнительно аналитика, архитектора и тестера. Сильно дорогих лучше не брать, желательно кого-нибудь подешевле, иначе финансовая выгода теряется. В результате программиста теперь не только менеджер на все совещания дёргает, а ещё и аналитик постоянно спрашивает, как он ту или иную новую фичу делать собирается, архитектор просит блок-схему нарисовать, и тестер постоянно пристаёт с вопросами: «Что и как тестировать?» Программисту совсем тяжко, и он начинает всё больше и больше не успевать.

Видя это, начальство добавляет в проект скрам-мастера, причём нанимает его менеджер проектов. Это не просто скрам-мастер: он не только процессы должен выстраивать, но и «за программистом поглядывать, дабы тот от работы не отлынивал и гадости ни про кого не говорил». А ежели он вдруг «на людей начнёт кидаться», то и поговорить с ним мог и проблемы его на психологическом уровне проработать.

Часть 2

Программист совсем зарывается, времени у него в обрез. Начинает срываться и нервничать. Другие на него с обидой смотрят. Получает больше всех, а ещё и ходит недовольный. Ну да ладно, чтобы ему настроение поднять, решают добавить в команду ещё парочку программистов. А из него сделать играющего тренера. Вот наняли ему двух начинающих разработчиков в помощь. Зарплату им дали самую маленькую, пусть пока опыта набираются. В итоге программисту совсем не скучно – на совещания ходит, аналитику помогает, архитектору блок-схему рисует, тестеру рассказывает, как тестировать надо, плюс двоих новичков в курс дела вводит. Ну как вводит – сам всё пишет да им показывает. А они смотрят, да как в анекдоте про сантехника, только ключи подают.

Время летит, проект пишется. Промежуточные показы не показываются, а после официальных релизов, как всегда, всё переделывается да переписывается. Новички подрастают и сами начинают код писать. Пишут так, что приходится ещё и за них нашему программисту всё переписывать. А они в ответ злятся, начинают на код-ревью к каждой его запятой придираться. «Ты нам расскажи, да покажи, зачем ты её поставил, и убеди нас, что это ничего не сломает». Программист с ними добрым старается быть, но время от времени срывается. Тут же прилетает скрам-мастер и начинает его успокаивать. Собирает всех вместе и начинает спрашивать нашего программиста, почему он так себя повёл нехорошо. Просит рассказать его о своих душевных травмах, да о том, что он о других людях думает. А остальные это всё слушают, да ещё больше убеждаются в мысли, что программист этот редкая какашка очень злобный и обиженный на весь мир человек.

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

В общем увольняют нашего программиста. Работу он сделал большую, молодец. Но такие нервные и скандальные работники нам не нужны, да ещё и с такой зарплатой. Он уходит и вскоре начинает всё ломаться и падать. Те, кто остался, винят во всём этом программиста. «Он специально перед увольнением всё попортил, чтобы без него всё работать перестало». Ну ничего, «мы сейчас всё перепишем и будет у нас не приложение, а мечта». У менеджера хорошие отношения с заказчиком, и он его уговаривает на глобальное улучшение всего проекта. Тот соглашается и работа начинает кипеть. Совещаний ещё больше становится, надо ведь не только новые фичи делать, но и старый функционал переделывать. Работы тоже прибавилось, и программисты наши, вчерашние новички, стали не успевать. Добавили им ещё трёх человек, чтобы они вместе, всеми силами взялись за проект и сделали всё красиво.

Часть 3

Проходит время, и вот он — «наш проект мечты» — закончен. Всё красиво и правильно сделано, только работает не так, как хотелось бы. Точнее, вообще не так всё работает. Заказчик злой, говорит: «Оставьте мне старый проект, а этот сами за свой счёт переделывайте». В общем, бьётся наша команда за свой проект не на жизнь, а на смерть. Но не выходит каменный цветок: после очередного показа заказчику тот принимает неприятное решение — разработку остановить, текущую версию стабилизировать и финансирование прекратить. Начальство в шоке, едут к нему всем составом, совещаются несколько дней и, как итог, умудряются договориться хотя бы о том, что проект минимально финансируют, на уровне технической поддержки. Так, чтобы он совсем не умирал и хоть как-то работал.

В итоге, всех с проекта убирают, оставляют только менеджера проектов да девопса, который знает, как его собрать да запустить. Во всём, конечно же, виноват тот программист, которого уволили. Но менять что-то уже поздно. С другой стороны, чего горевать — зарплата платится, работа делается. Ну как делается: сидят менеджер с девопсом на работе, чай пьют, анекдоты травят, в общем, неплохо время проводят.

Спустя какое-то время проект решают оживить, да вот только беда в том, что никто не знает, как он работает. Менеджер в код не лез никогда: во-первых, «не царское это дело», во-вторых, не разбирается он в нём, смысл лезть. Девопс тоже этим не занимался. Приглашают очень дорогих экспертов, те долго в код смотрят, головой качают, да языком щёлкают. Ходят задумчивые и расстроенные. В итоге начинаются долгие совещания и разговоры, по результатам которых решают писать всё заново с нуля, так как оживить такое в принципе невозможно.

Дорого это, конечно, но вроде как ещё новые заказчики нарисовались: сказали, что такую же вещь себе хотят и платить за это готовы. Руководство воспряло, даже решило из своего кармана это профинансировать. Перспективы-то знатные вырисовываются. Глядишь, с таким интересом к проекту вскоре весь мир им пользоваться будет.

И вот набирают они опять команду. Деньги теперь есть, и берут только самых лучших и дорогих. HR-отделу строго-настрого сказали, чтобы те только лучших искали. Собеседования сложные решили устроить: теперь только «звёзды» должны работать. И вот стали новые программисты приходить. Один другого сильнее, краше и умнее. Речи такие между собой ведут, что ощущение — они не люди, а инопланетяне какие, так как понять, о чём они говорят, никто не может.

Самого грязного и занудного умного и трудолюбивого, делают тимлидом, и наш менеджер проектов начинает уже с ним на все митинги ходить. А аналитик и архитектор с тестером постоянно его спрашивают, как им свою работу делать. Он, конечно же, «играющий тренер», да вот только не новички теперь в проекте, а матерые волки. И следят они очень пристально за каждым его шагом. Не дай бог споткнётся где, переменную не так назовёт или алгоритм какой не оптимально напишет — вмиг его на другого заменят.

Споры и дебаты на другой уровень вышли, могут часами, а иногда и днями длиться. Но работа кипит, приложение обещает быть очень продвинутым. Даже старый заказчик духом воспрял. Да вот только опять «не выходит каменный цветок» у команды мечты. Выглядит, конечно, он лучше прежнего, но вот работает хуже. То там сглючит, то здесь. Да и пользоваться им не так удобно, сложный стал, опций много — хоть специально людей обучай, которые бы с ним работать могли.

Плюс стоить он теперь стал во много раз дороже, чем прежний. Кучу денег в него вложили, а результат явно не тот, которого ожидали. В общем, начальство расстроено, людей постоянно увольняет, взамен им новых нанимает, деньги утекают, а толку мало. Зато всё теперь «по-серьёзному»: и фирма большая, и программисты сплошь дарования. Слава идёт хорошая о компании, люди это видя начинают у неё продукты всякие заказывать.

И теперь уже много проектов, и один другого перспективнее. Опять кучу менеджеров и программистов нанять можно. А пока они с заказчиками бодаются — ещё и новые проекты найти. Так, глядишь, из десятка-другого проектов один да выстрелит и окажется тем самым прибыльным и успешным. А если и не найдётся такого, то пока остальные проекты загнутся, они новых клиентов найдут и для них чего-нибудь напишут. Так вот расти и процветать будут.

Кстати, менеджер наш тем временем вырос до руководителя группы проектов. Свои ошибки учёл и нанял себе советников — одного специалиста по программированию, другого из сферы деятельности заказчика. И теперь они вместе собираются на митинги и решают, как программисты должны свои проекты писать.

Митинги долгие и интересные, на которые время от времени приглашают программистов и объясняют им, как правильно надо код писать. Это в дополнение к тем митингам, на которые их и так менеджеры проектов таскают. Плюс обсуждения с аналитиками и архитекторами и тестерами с них никто не снимал.

Сказка ложь, да в ней намёк

Это выдуманная история, и если кто и заподозрил какую фирму в ней, то это лишь его фантазии. Конечно, такие не выживают, и вокруг нас только успешные компании. А если и были такие или похожие на них, то они давно уже «канули в Лету».

У меня большой опыт в программировании, поэтому видел я всякое. Но в целом, анализируя свою работу, я пришёл к выводу, что не столько успешные технологии и толковые программисты влияют на успех проекта, сколько грамотные менеджеры и организация процесса разработки.

На мой взгляд, странно ожидать от дешёвого менеджера проекта серьёзных результатов, когда он в программировании в принципе не разбирается. Да, есть исключения, но на то они и исключения, чтобы подтверждать правило. Были у меня такие случаи, когда невольно приходили ассоциации, что мы все в цирке, и участвуем в каком-то очень странном представлении.

Когда у руля оказывался бывший разработчик, вероятность успеха была выше, хоть и не всегда. Причём реально бывший разработчик, а не тот, кто просто по специальности отучился и потом удачно менеджером проекта устроился. Хотя надо признать: и с такими руководителями у меня иногда тоже возникали разные ассоциации.

Та же история со «звёздами»: были в моей практике случаи, когда большое количество амбициозных и талантливых разработчиков в коллективе приводило к очень посредственному результату. Не давали эти «звёзды» друг другу подняться: стоило только кому-то перспективное решение предложить, сразу находился тот, кто это решение оспаривал. Даже если кто-то из них сумел как-то свою идею продвинуть и какой-то прорыв совершить, далее его могли так «заклевать», что он мог с проекта вылететь — если, конечно, вовремя это не пресекалось. С другой стороны, если не давали его «заклевать», то другие «звёзды» с проекта уходили. В общем, не так всё просто.

Понятно, что случались всякие истории. Были проекты, где не было такого сильного контроля, ожиданий и конкуренции, и в них можно было отличиться. Но как только проект «выстреливал», тут же набегали и «звёзды», и «эффективные менеджеры». Также были успехи, которые, казалось, случались вопреки всему. Ну и конечно же были нормальные проекты, где всё шло гладко и ровно.

Я сам был программистом, менеджером проектов, тимлидом и играющим тренером. Поэтому знаю, как это работает не понаслышке. Кроме описанных выше историй, есть ещё тысяча и один способ завалить проект. Это могут быть конфликты внутри команд, токсичные коллеги, лоу-перформеры (те, кто делает вид, что работает), странные правила и подходы внутри компании и многое другое. Дурное дело не хитрое, а вот сделать так, чтобы проект действительно был успешным, — это про команду, где каждый знает и честно делает своё дело.

Кстати, напоследок тот самый анекдот про сантехника:

Пришёл сантехник со своим учеником канализацию ремонтировать. Подходят к открытому люку, из которого бурлит вода, страшный запах. Опытный сантехник ныряет, через минуту выныривает и говорит ученику:
— Подай газовый ключ!
Ученик подаёт. Сантехник ныряет, опять выныривает:
— Подай ключ на 17!
И снова в воду. Так продолжалось несколько раз. Затем вода ушла, сантехник весь мокрый и вонючий вылезает из люка и гордо говорит ученику:
— Учись, сынок, а то так всю жизнь и будешь ключи подавать!

P.S.: На самом деле доля успешных проектов в ИТ не так уж велика. Разные исследования показывают примерно одно и то же:

• Linberg (2019, International Journal on Informatics Visualization) — успешными можно считать около 35 % проектов, если мерить по срокам, бюджету и качеству.

• CHAOS Report / AvenDATA (2015) — только 15 % проектов завершились так, как планировалось.

Есть и другие данные, но общий вывод прост: никакой универсальной методики нет, и всегда остаётся риск, что всё пойдёт не так, как хотелось бы.

Если статья понравилась — ставьте лайк.