Привет Habr, добро пожаловать в ад проект-менеджмент. Вместо Данте сегодня я буду разбирать свои грехи (а их много) как руководитель и заказчик на каждом этапе разработки ПО, а вы можете за компанию. Вергилий присоединиться, к сожалению, не сможет, у него омикрон. По ходу разберемся.
Я работаю в IT-сфере относительно недолго, но ошибок накопилось много, причем таких, которые вполне возможно было предотвратить, если кто-нибудь своевременно сказал бы перестать страдать фигней. Заказчик как правило в позиции власти, так что мотивации у него признать свою неправоту мало, а проект-менеджеру часто неловко это объяснить. В этой статье хочу обсудить многочисленные грабли, на которые пришлось наступить, как избежать это самим заказчикам, и что могут сделать проект менеджеры, чтобы с этим справиться.
Важно иметь в виду, что не все проблемы может решить руководитель заказчика, проект-менеджер, или даже сам заказчик в одиночку. Чтобы ситуация улучшилась значительно, важен комплексный подход, но даже если будет исправлено что-то одно – это уже хорошо, главное начать. Но помните что даже самый аккуратный подход и тон могут быть неправильно или негативно восприняты заказчиком, как пробовать это внедрять – ваше решение.
Предупреждаю, что путешествие в глубины будет долгим, так что налейте чаю и подготовьтесь морально. Учтите, что я не несу юридическую ответственность за ваше следующее нападение на заказчика или последующее увольнение. Если готовы, начинаем спуск.
1. Лимб – заказчик долго не мог сойтись на решении, дождался месяца до дедлайна, поторопился с решением и схватился не за тот проект
Открывая первую дверь, мы сразу же оказываемся в конференц-зале, и видим привычную картину: длинный стол, по всем краям покрытый топ-менеджерами, где-то вдалеке слышно, как ген. дир. орёт, а финансовый директор оправдывается. Что именно обсуждают не важно, да и уже никто особо не помнит. Они здесь сегодня уже 9-й час, лица у всех унылые, спиной к нам кто-то на компе подбирает путевку в Турцию.
Здесь, конечно же, собраны самые грубые нарушители, и далеко не везде всё настолько плохо, но все же такое встречается достаточно часто. Решения на верхушке компании всегда очень важны; неверное решение для конгломерата грозит потерей огромной суммы денег, а для маленькой компании – банкротством. Поэтому особенно удивительно, что решения на верхушке часто наименее объективные и структурированные во всей компании.
Это и является часто ключевым грехом, из которого растут многие проблемы: нерешительность и последующая импульсивность. Чем быстрее вы примете решение, тем больше времени будет у вашей проектной группы проработать решение, и тем эффективнее будет это решение. Иногда нерешительность будет казаться осторожностью, и определить, где эта грань – ваша ответственность. Разумеется, не следует безрассудно хвататься за первую пришедшую в голову идею во имя скорости, это тоже, как неудивительно, к классным решениям не приводит.
Также иногда менеджмент переходит вообще в офисную политику или бюрократию, и решения принимаются независимо от экономической пользы проекта. Здесь кроется второй наш грех: потеря смысла решения. Если вы руководитель организации, разумеется, одна из ваших ключевых целей – это предотвращать. У вас ограниченные экономические ресурсы, и чем больше из них сливается на такие обсуждения, тем меньше пользы вы сможете принести вашим стейкхолдерам: клиентам, сотрудникам, и акционерам.
И третий мне сложно описать иначе, как словом «необъективность». Зачастую управленцы и топ-менеджеры попали в свою позицию за счет большого количества качественных решений в прошлом, и за счет этого выстраивается самоуверенность. Чуйка и управленческие инстинкты крайне важны, но нельзя вечно опираться только на них, в какой-то момент не повезет. Первое или даже второе впечатление должно стать опорой решения, но до того, как его передаем в работу, субъективность должна плавно перелиться в объективность.
Если вы управленец и можете повлиять на процесс напрямую, то все эти проблемы реалистично преодолеть, или хотя бы минимизировать, процесс принятия решения лишь должен быть стандартизирован. Если вы проект-менеджер, то это разумеется значительно сложнее, но повлиять все равно возможно. Даже если сам заказчик это не осознает, общие принципы того, что опишу ниже, действуют на всех уровнях организации, и многие заказчики будут даже приятно удивлены, если поможете им сформулировать бизнес-план и их мысли. Опять же, тут есть шанс что обидятся или разозлятся, так что осторожно, обязательно создавайте впечатление, что это их идея и они к этому пришли сами.
Чтобы реализовать вменяемую систему, вам нужно:
иметь стоящие и качественные метрики и формулировать цель цифрой;
отталкиваться от нужд стейкхолдеров и задействовать правильных людей в принятии решений.
Решение #1 – Метрики
Первым делом стоит сказать, что метрики – очень мощный инструмент, но только если пользоваться осторожно. Хорошие метрики помогут бизнесу двигаться в верном направлении, но неверная метрика поможет еще быстрее утонуть. Сказал бы даже, что огромный процент зла в обществе как раз появляется из-за неверных метрик.
Смотрим закон Гудхарта: «Любая наблюдаемая статистическая закономерность склонна к разрушению, как только на нее оказывается давление с целью управления [экономикой]». Вкратце – как только метрика становится целью, она перестает быть хорошей метрикой.
Казалось бы, что это делает метрики бесполезными, но это не совсем так. Главное, чтобы метрика не была единственным, на что опирается компания.
Пример стандартной проблемы с метриками: стори поинты и велосити. Если единственная цель команды разработчиков – увеличивать производительность, измеряемую в общем количестве стори поинтов, и ваша команда выполняет столько же работы, но плавно все больше завышает оценки, то поздравляем, клоуна на день рождения сына искать не придется. Но это не значит, что стори поинты или любая другая метрика бесполезны.
Важны три момента:
Параллельно с этим вести другие метрики команды и клиента. К примеру, удовлетворенность пользователей системами, количество багов на проде, качество пул-реквестов и т.д. В этом случае коллеги не могут просто пожертвовать одним из других принципов ради скорости.
Зафиксировать четкие значения бейслайна, т.е. изначальных значений, так как это делает искусственную инфляцию значений более сложной затеей.
Не поверите, но иногда стоит объяснить сотрудникам смысл метрики. Метрика лишь описывает цель, но если настоящую цель не зафиксировать, то другого варианта-то особо не остается, кроме как зациклиться на цифре и рискнуть, что сделаем не то. Даже количество стори поинтов в первую очередь измеряет не скорость разработки, а объём полезной функциональности, которую команда может создать для своих пользователей. Идеальный вариант – даже обозначить команде цель, и дать подобрать метрику самостоятельно, но свои «коммунистические» теории я, пожалуй, отложу на следующий раз.
Также важно понимать разницу между метриками отставания (lag indicator) и опережения (lead indicator).
На метрики отставания сложно повлиять напрямую, и они меняются с задержкой. Самый стандартный пример – это валовая прибыль. Нет единственного действия, за счет которого я мог бы увеличить прибыль на 100 рублей.
Метрики опережения как раз отслеживают результаты, которые зависят напрямую от нас, и которые должны приводить к улучшению результата метрики отставания. В этом случае пример – количество звонков клиентам. Не учитывая другие факторы, чем больше я звоню, тем больше я привлеку клиентов, и тем больше получу прибыли.
В разных случаях вам нужны разные метрики, но практически всегда если ставите задачу проект-менеджеру на долгий срок, то это будет индикатор отставания. Если на 100% уверены, что знаете какая метрика опережения ключевая в этом случае, то одумайтесь и все равно остановитесь на метрике отставания, а метрику опережения оставьте на плечах проект-менеджера. Если вам как проект-менеджеру вручили метрики опережения, то попробуйте отстоять позицию. Обоснуйте тем, что соберете информацию и покажете уже резонные метрики руководителю, который их согласует.
Мы немного определились как убедиться, что метрика будет полезной и подобрали верный тип метрики, но остается основной вопрос – какие метрики отставания ключевые и какие нужно улучшать? Тут как раз остается ответственность на том-менеджменте, ибо им за это платят.
Если все же не уверены, то задайте себе вопрос: «Если бы все остальное осталось как есть, улучшение какой части бизнеса принесло бы больше всего пользы?» И если у вас всплывает мысль, нафиг это предлагать, это же и так очевидно, в следующий раз спросите своего заказчика почему они решили именно над этим работать, ответ вас может сильно удивить.
Иногда метрика может быть ценной, но при этом вы не сможете на нее повлиять. Таких тоже нужно избегать. Некоторые вообще вне контроля компании, такие как рост экономики, а некоторые могут уже быть близки к пределу, и дальше их увеличить не получится. Если заказчик выберет цель которую нереально достичь, а проект-менеджер на нее подпишется, то плакать придется обеим сторонам.
И в конце концов метрики помогают убедиться, что все на одной волне. Пока решение в голове, а не на бумаге, всем будет казаться, что они поняли задачу так же как и все остальные, а на практике редко так получается.
Возьмем пример: «Мы хотим систему обработки обращений клиентов для улучшения качества сервиса». До того, как продолжите читать, задумайтесь о том как бы вы это восприняли. По моему опыту, что это может значить:
обращения должны обрабатываться быстрее;
нужно сократить штат колл-центра;
хочется больше конверсий продаж с обращений;
скоро запускают пиар кампанию и хотят чем-то похвастаться;
случайно пообещали руководителю, что это уже есть и нужно соответствовать минимальным требованиям как можно дешевле и быстрее.
И так до бесконечности.
Как только приходится это зафиксировать цифрой, то такие недопонимания начинают испаряться. Одно дело «Мы хотим систему обработки обращений клиентов для улучшения качества сервиса», другое «Мы хотим снизить среднее время обработки обращения с 20 минут до 6 минут в течение 6 месяцев».
Как видите выше, важно чтобы в цели выраженной метрикой было три составляющих:
начальное значение;
ожидаемое значение;
срок.
Т.е. «Увеличить {{количество обращений}} с {{100 в день}} до {{600 в день}} до {{конца года}}». Если задача просто «Увеличить {{количество обращений}}», то это лучше, чем ничего, но усложнит жизнь всему коллективу, так как будут недопонимания об уровне успеха которые захотите достичь. Вам может 600 хочется, а все остальные считают что 300 потолок. Если 600 возможно, то нужно всех нацелить на это с самого начала, а если 300 действительно потолок, вам лучше пересмотреть цель с самого начала.
На этом этапе стоит подключить тех, кто будут эту метрику пытаться достичь. Конечно же будет скепсис, что в интересах команды занизить метрику, но если примете решение, не задействовав всех ключевых игроков, то вам не так просто будет их убедить выкладываться ради этой цели.
НО! и это «но» огромное – такая метрика на проект не для того, чтобы ее закинуть на команду разработки. Команда разработки не может подписаться на достижение нужного результата по компании в целом, так как многие факторы успеха вне контроля разработчиков. Они смогут приоритизировать самый актуальный функционал, но систему все равно придется внедрять, придется набирать операторов, и придется контролировать их работу. Если написали идеальную систему, но не набрали достаточно сотрудников, чтобы обслуживать клиентов, то это не вина разработчиков.
Подводим итоги:
До того как брать задачу в работу, оцените какие цели для вашей компании самые важные.
Убедитесь, что это цель на которую реалистично повлиять.
Сформулируйте ключевые метрики которые хотите отслеживать в формате «Увеличить {{ X }} до {{ Y }} в течение {{ T }}».
Определитесь, что это метрика отставания и что достижение вообще реалистично, привлеките ключевые лица.
Передайте информацию об этих метриках проект-менеджеру на этапе постановки задачи, чтобы они могли это учесть.
Если же вы не управленец, а проект-менеджер, то у вас, к сожалению, выбора меньше, но вы вовсе не беспомощны. Когда передают проект и вы собираете высокоуровневые требования, даже если вам вначале не предоставили метрики, которыми будет оцениваться успех проекта, вы можете самостоятельно пытаться догадаться, давать предложения, и пробовать согласовать их с заказчиком.
Вам это позволит более чётко сформулировать высокоуровневые требования и задачи, и вам проще будет доносить потребности команде разработки, с которой работаете. Заказчик будет более четко понимать свои же требования, и в будущем будет проще организовывать продуктивный диалог, и решения команды можно будет обосновывать на основании этих договоренностей.
Но вам не надо формулировать это в настолько четком формате, как описано выше, это больше нужно самому заказчику для отслеживания своих успехов после запуска софта. Чтобы понять смысл разработки, вам зачастую как раз достаточно понять цель на уровне «Сократить среднее время обработки сообщений». Если вы попробуете сами это сформулировать в полную версию, то заказчик может начать это ассоциировать с вами, и, если эта цель, которая во многом от вас не зависит, попадет в высокоуровневые требования, вам это жизнь очень сильно усложнит. В лучшем случае при провале заказчик все свалит на вас, в худшем не будет принимать работу, пока цель не будет полностью достигнута.
Если заказчик продвинутый и уже есть эти цели, то важно поддерживать дистанцию между своей ответственностью и достижением цели. Речь всегда должна идти о том, как продукт поможет заказчику достичь своих целей, ни в коем случае не о том, что продукт решит проблему или по умолчанию приведет к выполнению цели. Если это делать аккуратно, то заказчик даже не заметит, но это задаст правильный тон для дальнейшего общения.
Вас в первую очередь должно интересовать:
Почему организация берется именно за эту цель, а не за другие.
Как успех достижения этой цели будет оцениваться, общими словами.
Решение #2 – Держать в приоритете нужды заинтересованных лиц
Стейкхолдер – любое лицо или организация, задействованная в проекте, или на которую проект повлияет.
При постановке целей, всегда нужно ориентироваться на три ключевые группы стейкхолдеров:
клиенты/пользователи – те, для кого этот продукт, или на кого он должен в первую очередь повлиять;
сотрудники – часто про них забывают, но важно чтобы сотрудники и коллеги были довольны нововведениями, так как от них зависит развитие компании не меньше, чем от клиентов;
акционеры/инвесторы/собственники – те, за чей счет эта работа будет по факту выполняться.
Тут значительно проще – при принятии решений важно, чтобы были учтены интересы всех трех групп. В экстремальных случаях может быть, что не учтены интересы ни одной из трех групп, и топ-менеджер пытается протолкнуть проект в каких-то личных целях, но как правило не все так плохо.
На практике чаще всего забывают лишь об одной из групп, но в каждом случае это может привести к серьезным последствиям:
Если не учтены интересы клиентов – особенно если это продукт, нацеленный на вывод на рынок, то его просто не купят. И заказчику, и команде разработки придется отчитываться, зачем потратили столько времени и денег на бесполезный продукт. Не всегда продукт прямо выводится на рынок, но даже внутренние разработки так или иначе как правило заканчиваются пользой клиенту, так что, если клиенту ни горячо ни холодно, тоже могут быть вопросы.
Сотрудники – так как мы в РФ, об этом забывают чаще всего, но угодить сотрудникам не менее важно чем угодить клиентам. Тут последствия иногда даже страшнее, но они не настолько очевидны и поэтому за такие промахи реже наказывают. Если сделали систему которая очень удобная для клиентов, но которую ненавидят сотрудники, то последующая демотивация может свести на нет те достижения, которые были достигнуты при разработке функционала, полезного для клиента.
Акционеры/инвесторы/собственники – так или иначе интерес в прибыльности, как правило, растет отсюда. Обычно наиболее удаленные от процесса, и поэтому меньше всего шансов, что именно они заметят, но у них больше всего власти над заказчиками, у которых власть над проектной группой. Поэтому если будет косяк, который затронет их, к примеру если по результату внедрения продукта значительно вырастут затраты, то последствия будут наиболее серьезные, вплоть до увольнений и замораживания проектов.
Чем больше цель построена на интересах этих групп, тем больше шансов, что в конце получим на руки объективно полезный продукт. До того как пустить в работу какую-либо крупную разработку, неплохо хотя бы устно проговорить, как это повлияет на каждую из трех групп.
Самый простой способ учесть как можно больше – это вовлекать самих стейкхолдеров, а если нет возможности, то тех кто больше всего варится в этой теме. Интересы собственников, как правило, избежать не так просто, т.к. крупные проекты согласовывают топ-менеджеры, которые отчитываются либо генеральному директору, либо собственникам напрямую. Даже если топ-менеджеры не участвуют напрямую, одна из ключевых ответственностей генерального директора – доносить общую стратегию и настрой этой группы стейкхолдеров всей компании.
Представителей пользователей тоже обязательно включать. Это как правило:
менеджеры по продажам;
операторы колл-центров;
сами проект-менеджеры и владельцы продуктов.
Даже если вы очень ответственный управленец и часто общаетесь со своими клиентами, вы никогда не будете настолько близки к этим стейкхолдерам как те, кто с ними работают на постоянной основе, и их мнение нужно обязательно учесть. В худшем случае вы потеряете чуть времени, а в лучшем получите ключевую информацию, которая спасет вас от потери миллионов рублей.
Аналогично с сотрудниками, которые будут работать через это программное обеспечение, независимо от должности. Тут особенно важно подключить не только руководителя, а и самих рядовых сотрудников, которые будут с этим взаимодействовать. Даже с самыми благими намерениями руководитель может не быть в курсе всех специфик рядовой работы.
Стейкхолдеры в каждой компании и на каждом проекте разные, и никак иначе не учесть все их нужды, кроме как задействовать стейкхолдеров напрямую. Это актуально, как на этапе принятия решения авторизовать проект или нет, так и при дальнейшей проработке. Поэтому важно, чтобы они были закреплены за рабочей группой на постоянной основе.
Одна из задач проект-менеджера максимально вливаться в контекст, а контекст заказчика понять сложно, не осознав их рабочую среду и силы, которые на них влияют. Узнайте кому хотим угодить и за счет чего, и, если возможно, запросите прямой доступ к этим стейкхолдерам, чтобы перепроверить идеи заказчика.
Часто решения заказчика кажутся странными и необоснованными, потому что у нас нет полной информации. Представьте, насколько сложно было бы играть в шахматы, если видите только четверть доски. Чем ближе вы общаетесь с стейкхолдерами, тем проще вам будет представить себя заказчиком, воспринимать истинную мотивацию их решений, и обосновывать свои решения им.
Пока я задумался, топ-менеджер все-таки определился с путевкой, поворачивается к нам, и просит сгонять ему за кофе. Пора выдвигаться. Впереди нас ждет второй круг - похоть, где караются те заказчики, которые до того, как обратиться к проект-менеджеру сами неверно поняли суть проблемы....
P.S.
Важно отметить, что специфики у каждой компании разные, и я не смогу никогда иметь дело со всеми заказчиками или всеми проект-менеджерами. Если ваш опыт отличается или есть что добавить, то буду очень рад увидеть это в комментариях. Спасибо за выделенное время, до скорого!