Однажды для знакомства с новым и многообещающим проектом федерального значения меня отправили на стажировку разгребать инциденты на первой линии. Рядом со мной работали молодые ребята, вчерашние студенты. С первого взгляда было видно, что ребята какие-то зашуганные, с постоянной тоской в глазах. Я решил подбодрить одну из своих коллег и начал издалека. На мой вопрос о том, чего она хочет от этой работы, моя визави честно ответила: «Я хотела бы не думать каждый вечер о том, чтобы уволиться».
Проблемы волшебников
Программист, подобно поэту, работает почти непосредственно с чистой мыслью. Он строит свои замки в воздухе и из воздуха, творя силой воображения.
Я работаю волшебником. Я вместе с коллегами воплощаю мысли в магию, которая изменяет мир. И я люблю свою работу. Жена, конечно, ревнует, но ведь сердцу не прикажешь.
Я хочу быть добрым волшебником. Я хочу делать программы, которые принесут пользу как можно большему числу людей. Я хочу, чтобы моя работа повышала уровень моих компетенций и мой социальный статус. Я хочу, чтобы результаты моей работы были признаны сообществом и достойно оценены.
Все эти цели могут быть достигнуты при моем участии в больших программных проектах в интересах крупных заказчиков.
Однако такие проекты, кроме любимой работы, новых знаний, опыта, денег и признания значимости, как правило, приносят тревожность, беспокойство, бессонницу, нервные срывы, сильную головную боль и выгорание. В итоге подспудно и незаметно формируется стойкое отвращение к былому объекту обожания. Почему-то и жену это тоже не радует... Как сказал кто-то из великих: «Страшно не то, что любовь уходит... Страшно то, что она уходит незаметно». После таких проектов уже не хочется быть волшебником. Если ты, конечно, не перешел на темную сторону.
По данным Standish Group выводы, сделанные на основании анализа результатов работы более 50 000 компаний, неутешительны: более половины программных проектов частично или полностью терпят крах. Показательно, весьма эпичное, название ежегодных отчетов, которые регулярно предоставляет эта организация, о состоянии дел в мире производства программного обеспечения - «CHAOS Report». По результатам этих отчетов, снова и снова, отмечаются основные факторы неудачных проектов:
неполные и неоднозначные требования и их частое изменение в процессе выполнения проекта вплоть до потери актуальности;
нереалистичные ожидания заказчиков при отсутствии стремления к сотрудничеству с разработчиками;
низкое качество менеджмента, которое включает отсутствие планирования работы проектных команд и отсутствие поддержки со стороны руководства компаний;
нехватка ресурсов и некомпетентность исполнителей.
Мир несправедлив. Чем крупнее программный проект, чем больше добра он может принести, тем больше вероятность того, что он пополнит число неуспешных проектов. При этом эксперты отмечают, что снижение количества неудачных программных проектов в начале века связано не с улучшением эффективности производства, а с общим снижением доли крупных проектов в индустрии программного обеспечения. Конечно, проблема успешности крупных проектов, иногда, может быть решена путем дробления таких проектов на более мелкие. Да здравствует Agile! Сразу значимость третьего фактора неуспешности резко снижается. Но что делать в тех случаях, когда нельзя «перепрыгнуть пропасть в несколько прыжков»?
Это не статистика, это какая-то депрессивная черная магия. К счастью, вся эта статистика собрана не в России. Но меня терзают смутные сомнения, что какая-то корреляция все-таки существует...
Уже давно количество строк кода в нашем проекте перевалило за два миллиона. И каждый раз, когда от заказчика приходят письма с просьбой «по-быстрому» переделать какую-нибудь «мелочь», я почему-то не рад тому, что мне опять предстоит сотворить чудо… Зачастую, для этого требуется совсем другая магия, чем та, которую я действительно люблю...
Мое предположение - беспокойство, бессонницу, нервные срывы, сильную головную боль вызывают ежедневные страхи. Именно ежедневные. Все знают, что когда-нибудь умрут, но, как правило, это никого не беспокоит.
Мне нужен антидепрессант, который спасет меня от выгорания на больших программных проектах в интересах крупных заказчиков.
Однако, чтобы выписать рецепт, надо провести диагностику болезни.
Фобии честных сотрудников
Сразу исключим из исследования те причины, которые связаны с нестабильной психикой и многократно продублированы на просторах Интернета: страх несоответствия занимаемой должности, страх делегирования, страх потери уважения, страх невостребованности.
Чего может боятся ответственный, умный и честный сотрудник? Например, исполнитель, который является профессионалом своего дела или опытный руководитель, который не боится политических интриг? Попробую угадать ежедневные страхи каждого из типовых персонажей крупного программного проекта.
Чего боится исполнитель?
Моя работа будет недооценена;
мне поручат делать работу, которая никому не нужна;
мне поручат выполнять работу, не соответствующую уровню квалификации;
мне надо будет вкалывать сверхурочно;
мне надо будет вкалывать, а успехи запишут на другого;
все ошибки блатных сотрудников свалят на меня;
все ошибки руководителей свалят на меня;
надо будет писать никому не нужные отчеты о проделанной работе;
все узнают, что я не знаю, как делать порученную работу;
я подведу своих коллег;
я выполню свою работу с недостаточным качеством, пострадают люди.
Чего боится руководитель проекта?
Я покажу свою некомпетентность;
я забуду поручение от руководства;
я забуду какое-то требование заказчика;
задач так много, что я не знаю за что хвататься;
мои сотрудники не выполнят поставленные задачи в срок;
у меня нет реальных инструментов воздействия на команду;
я не знаю, как убедить руководство, что сроки нереальные;
я не знаю, как убедить руководство, что нужны дополнительные специалисты;
я не знаю, как доказать руководству, что принятые ими решения ведут к катастрофе;
я неправильно расставляю приоритеты работы;
я подпишусь под невыполнимые условия;
моя работа недооценена;
работа моей команды недооценена.
Чего боится руководитель департамента?
Я покажу свою неосведомленность о состоянии дел на проектах;
я недооценю риски;
я переоценю имеющиеся силы;
будут сорваны сроки проекта;
заказчик потребует выплату неустойки;
я упущу важный пункт договора.
Чего боится директор компании?
Проект не окупится;
меня подведут партнеры;
я испорчу репутацию компании;
я буду выглядеть неавторитетно.
Чего боятся представители крупного заказчика?
Я нарушу регламент/инструкцию/предписание;
меня назначат ответственным за ошибку в документе;
я буду виноват, что принял некачественный продукт.
Предпосылки к депрессии
85% проблем компании - в системе, а не в персонале. Менеджмент - это наводить порядок в процессах, а не раздавать нагоняи сотрудникам.
Если все сотрудники на проекте честные, умные и хотят делать добро, откуда взяться страхам? Бояться-то некого.
Однако страхи - это только симптомы, которые мешают жить. Правда, эти симптомы, в отличие от кашля, сопливого носа и слезящихся глаз не очевидны. Никто не хочет афишировать свои страхи. В последнее время появилось множество лекарств, которые могут на целых полдня снизить неприятные ощущения от болезни. Правда, при лечении они помогают так же, как пудра спасает от прыщей. Хорошие врачи излечивают причину.
Если у ваших сотрудников в зимний период постоянно случаются острые респираторные заболевания, может стоит проверить помещение на предмет сквозняков и отопления? Если ваши страхи совпадают с вышеперечисленными, я попробую угадать из какого угла у вас дует.
В последнее время почти не встречаются предложения о вакансиях руководителей проектов, в которых бы не было сакральных слов Scrum и PMI (PMP). Только вот действительно ли эти чудо-фреймворки могут быть применены на крупных программных проектах? «Конечно!!! А разве может быть иначе!!!» - наперебой будут вас убеждать подавляющее большинство коучеров YouTube. На фоне этого безудержного энтузиазма статья «Управление разработкой крупных программных систем» директора центра по технологии программного обеспечения компании Lockheed доктора Уинстона Ройса, опубликованная в августе 1970 года в США в журнале IEEE, звучит гораздо более убедительно, чем «Черная книга Scrum» Ивана Селиховкина. И то, о чем Ройс не говорил, «цитируется» снова и снова. Жалко, что Иван не написал книжку «Черные страницы PMBOK».
Вдохновленный умными книжками, я тоже не раз пытался применить эти методики на живых проектных командах. Однако мои попытки, как правило, приносили больше вреда для проектов, чем пользы. Сначала я думал, что я что-то не так делаю. Ведь где-то это действительно работает.
И это действительно работает. Я уточнял. На продуктовых проектах. На небольших проектах, в которых интересы коммерческого заказчика представляет один человек. В случае малого предпринимательства - сплошь и рядом...
А на заказных проектах в интересах крупных заказчиков как-то не очень. То ли руководители попадаются неправильные, то ли проекты.
Правда, некоторые руководители уверены, что эти методики работают везде и всегда. Когда я встречаю статьи об очередном успешном внедрении Agile в какой нибудь крупной компании, я очень хочу им верить. Великая вещь, эта вера. Еще Наполеон говорил: «Если ты веришь в свою победу - ты уже наполовину победил». Правда, как правило, моя вера живет до первого столкновения с результатами этого Agile в жизни. Видимо их вера сильнее моей... А с другой стороны, какой дурак на Плюке правду думает? А как может быть иначе, если 200-страничную инструкцию по применению Agile в корпорации согласовали все директора департаментов и подписал Сам Генеральный? Они не могут ошибаться… Как в армии учили: «Если начальник штаба сказал, что барсучок - это птичка, не думай, ищи крылышки». Мы вас заставим Agile любить…
А дальше - «четко» по инструкции:
не стоит заморачиваться над проектной документацией, потом эту макулатуру оформим (один знакомый начальник отдела прямо так и высказался);
главное - не испортить отношения с заказчиком, не будем надоедать ему бесконечным уточнением непонятных требований, сделаем продукт, а там договоримся;
писать планы незачем, они все равно не выполняются;
измерять вклад каждого сотрудника не имеет смысла - мы одна команда!
Какое-то тотальное недопонимание. Например, всем понятно, что один из самых грозных хищников планеты - касатка, совершенно не проявит своих качеств посреди Сахары. Но далеко не всем понятно, где стоит применять импортные эффективные методики управления, а где - нет.
С другой стороны, а что остается применять? Что у нас там, на щедром рынке? Нет ничего такого, чтобы не думать? Чтобы поменьше свой мозг напрягать? Чтобы дать книжку подчиненным, а дальше пускай они сами. Как-нибудь - они у меня умные. Такое бы готовое решение, на все случаи жизни. Какой ассортимент сегодня? Богатый выбор? В глазах рябит: Scrum, Kanban, XP, RUP, RAD, PMBOK, COBIT, PRINCE2, ITIL… Да, я уже это пробовал, но как-то не прижилось в нашем климате. А своего отечественного ничего нету? ГОСТ 54869? ГОСТ 21500? Я вас умоляю… Это ж перевод с английского… И то, не всех слов... А когда привезут, не в курсе? Есть ГОСТ 34-й серии? Так это давно протухло. По крайней мере, так говорят. Может не протухло? Говорите, кто-то еще использует? И даже взлетает? А успешные посадки после взлетов зафиксированы? Говорите, зафиксированы? Неоднократно и в большом количестве? Да нет, Вы меня неправильно поняли... Я имел в виду совсем другое.
Раз за разом наблюдаю, как «продвинутые», но неопытные менеджеры самозабвенно пытаются заставить своих «касаток» ловить тушканчиков в пустыне. А менеджеры менеджеров дают мудрые указания. Строго по PMBOK… Или по ITIL… Прямо готовые справочники по нахождению виновных на проекте. Там плохого не посоветуют. Всегда найдется что-нибудь, чего руководитель проекта не учел или не сделал. Это ничего, что соответствующей инфраструктуры нет. Не надо оправдываться, что ресурсов недостаточно. У хорошего руководителя на все должно хватать времени своих подчиненных.
Как показывает не очень репрезентативное исследование, более опытные руководители, имитируя Agile, культивируют старую, проверенную методику под названием «Барин и холопы». Не этот ли способ управления применяется у вас на проекте? Может здесь кроются причины вашего дискомфорта?
Конечно, нет, чего напраслину разводить! Наш барин руководитель добрый, умный и справедливый. Не чета другим. Лишнего не потребует, тушканов ловить не заставляет, все по делу. Всего, конечно, не упомнишь, чего он там наговорил…
Эту ситуацию очень здорово описал Андрей Тысленко:
«Мы проводили эксперимент. Не один десяток раз. Не одну сотню раз. Мы берем и опрашиваем директора. Дайте перечень задач, которые Вы поставили за последний месяц. Из них укажите те, которые Вы считаете выполненными. Потом мы берем всех людей, которые сидят под директором, и задаем им очень простой вопрос: напишите все задачи, которые вы получили от директора и которые вы считаете, что выполнили. Получается забавная вещь. В случае, даже когда уже есть информационный контроль, но не выделен человек, который последовательно и шаг за шагом а) фиксирует и б) отслеживает выполнение, то самый большой процент пересечения этих задач составляет 6% (шесть процентов)».
Только если допустить, что сказанное выше - правда, уже как-то не по себе. Сразу становится понятным, что распоряжения начальства куда-то надо записывать. Чтобы можно было понять, что сделано, а что - нет. Моя статистика общения с себе подобными показывает, что на программных проектах для использования в качестве общей записной книжки лучше всего подходит JIRA. И все основные задачи туда и записываются. При этом все задачи разделяются на типы, и для каждого типа, как правило, проектируется свой рабочий процесс выполнения (workflow). Надо вывести бардак под корень! Создать совершенный workflow. Для каждого типа задач. И на каждый этап назначить своего ответственного.
Это только для двух типов задач… Только при одном беглом взгляде на эти схемы мой мозг начинает жалобно скулить о своей генетической неполноценности и ущербности. Ну оно и понятно. Проект - это сложная организационная система. Понятно, что все детали охватить не удастся, ведь не формализуешь процессы на все случаи жизни. Главное - принцип Парето соблюсти. Правда, до 80% деятельности может остаться вне поля зрения. Но это же неважные 80%. По крайней мере, пока неважные. Да и вообще, шут его знает, как работу эту творческую прогнозировать.
Только главное - что-нибудь не забыть в workflow, а то потом замучаешься статусы синхронизировать. Зато если построить такие workflow, всегда можно сказать, в каком состоянии находится выполнение той или иной важной задачи. Правда, не всегда можно сказать, кто виноват в такой ситуации. Поди разберись. На одну задачу - семь нянек. Зато системность, вроде, соблюдена.
Ведь еще Элияху Голдрат говорил:
«Мы все понимаем системный подход. Мы знаем, чтобы его применить надо начинать не с одного отдельно взятого аспекта или отдельно взятой функции, а с их совокупности. А затем мы не знаем, что с этим делать, и возвращаемся к тому, что занимаемся каждым из аспектов в отдельности. Я думаю, что мы не должны сдаваться.
Мы должны положиться на интуицию, которая привела нас к осознанию того, что мы должны применять системный подход. Почему мы утверждаем, что мы должны применять системный подход? Потому что интуитивно мы знаем, что если мы предпринимаем какие-либо действия в одной функции, это сказывается на других функциях, и то, что может локально выглядеть хорошо, может негативно сказаться в каком-либо другом месте, что говорит о том, что мы знаем о существовании причинно-следственных связей, которые пересекаются между функциями. Мы знаем, что причина, имеющая место в одном отделе может вызвать последствия в других отделах.
Если дело обстоит таким образом, почему бы нам не установить причинно-следственные связи до того как мы примем решение, что нам делать. Разве это так трудно?»
Причинно-следственные связи между задачами установить, может не трудно. JIRA-то это позволяет. Потом-то что с этими связями делать?
Подозреваю, что между описанными условиями работы и страхами честных сотрудников на проекте существует определенная зависимость. Но эту зависимость надо доказать.
Продолжение следует…..
Несколько лет назад, перед этим изрядно отравив жизнь не одной проектной команде попытками внедрения прогрессивных методов управления, на новом месте работы, придя в ЛАНИТ, я решил начать «с чистого листа». При этом, я решил при организации работ на своем проекте делать не то, что «признано» и «правильно», а то, что, на мой взгляд, реально помогает снижать нервозность участников программного проекта. В качестве платформы для повышения эффективности управления была выбрана JIRA, однако учет первичных данных был организован не совсем традиционно. И для анализа этих данных были разработаны собственные инструменты. Первые результаты этого эксперимента я опубликовал на Хабре в своей статье «JIRA как средство от бессонницы и нервных срывов». С самого начала я предполагал, что этот подход будет раскритикован в пух и прах. Но, к сожалению, конструктивной критики случилось неожиданно мало. Многие вопросы моих оппонентов сводились к тезису, который был сформулирован в одном из комментариев:
Однако в настоящее время этот подход сам по себе, без применения средств физического и административного насилия, распространился на шесть проектных групп нашего департамента. Один из моих знакомых тимлидов из другой, маленькой компании после долгих сомнений попробовал применить такой подход для своей команды и как-то на нем и остался. Кроме инструментов, описанных в первой статье, появились дополнительные дашборды, которые позволяют оценивать текущие риски проекта и более точно формировать управляющие воздействия для сотрудников проектной команды.
Однако многие продолжают недоумевать: «Каким именно образом JIRA позволяет купировать выгорание на проекте»?
Но прежде, чем ответить на этот вопрос, я решил проверить свою гипотезу в отношении существования вышеперечисленных страхов и их зависимости от условий проекта. Действительно ли все так или это только мои фантазии?
Хотя я, конечно, волшебник и у меня богатое воображение, но я не телепат и не экстрасенс. И никогда не был директором компании. Поэтому я хотел бы просить вас помочь мне проверить предположения, высказанные в этой статье, поучаствовав в открытом и абсолютно анонимном опросе «Фобии честных сотрудников на проекте». Любая критика приветствуется.
Анализ результатов этого опроса, а также апробированные схемы применения моего антидепрессанта я планирую опубликовать в своем следующем посте.
P.S. Эта статья входит в цикл статей под названием «Правила своевременного приготовления вкусного программного обеспечения», который я использую как неформальный регламент команды на заказных программных проектах, в условиях, когда «правильно» и «как лучше» сделать нельзя, но делать все равно надо . В блоге проекта SMART-UP вы можете ознакомится с актуальным содержанием этой серии , с учетом изменений и уточнений произошедших после публикации этой статьи на Habr. Основной лейтмотив этой серии статей — обеспечить эволюционное совершенствование качества программных проектов на основе повышения эффективности управления. Другими словами — сформировать прикладные способы роста по уровням модели CMMI.
