03.04.2018
В сфере автоматизации процессов в автобизнесе постоянно и довольно остро стоит вопрос эффективности. Как построить процесс так, чтобы он был оптимален с точки зрения бизнеса, роста сотрудников, изменяемости, прозрачности и многих других факторов? Где та самая «серебряная пуля», которая позволит решить сразу все проблемы и избавит вас как руководителя от головной боли?
На звание этой «серебряной пули» по очереди претендуют модные (и не очень) методологии: Scrum, Kanban, XP, RAD, FDD и т. п. Регулярно появляются новые способы, подходы и инструменты. Бизнес-консультанты приходят в компании и делятся своими ноу-хау за немалые деньги, рассказывая, как правильно. А при этом хорошо бы ещё и дёшево, не так ли?
И здорово, если люди могут сформулировать потребности, которые они хотят удовлетворить с помощью того или иного процесса. Но часто бывает так, что без раздумий просто внедряется модный подход, что в итоге приводит к недовольству участников либо к неэффективности для бизнеса – в современном мире с его высокими темпами, со стартапами и высокой конкуренцией результат подобной неосмотрительности может быть плачевным.
Давайте подумаем, что требуется от процесса, какие проблемы нужно решить и какие подходы для этого используют. А заодно я расскажу о том, как делаем мы в Майсапп. Это уже четвертый мой пост в нашем блоге. Но на всякий случай представлюсь снова: я – Виталий Новицкий, генеральный директор Майсапп.
Участники процесса
Говоря о процессе, в основном говорят об участниках. Есть ещё условия, результат, ресурсы, цель и т. д. Но организация совместной работы таким образом, чтобы она была комфортной и эффективной в большинстве случаев.
Все работники компании каждый день приходят в офис с разными целями. Хорошо если эти цели удаётся сбалансировать и совместными усилиями достигать хороших бизнес-показателей. Но очевидно, что у бизнеса и рядовых сотрудников цели и ценности изначально разные. Кто-то копит на жильё, новую машину, отпуск. Кому-то интересно живое общение и личностное развитие. Бизнес же зарабатывает деньги и воспринимает сотрудников как ресурсы, позволяющие достигать поставленных целей.
Согласитесь, немногие компании существуют просто для того, чтобы платить зарплату сотрудникам, потому что они хорошие люди (если такие вообще есть). Цели другие, хоть и не всегда разделяемые работниками.
И мне кажется, что в этом сложном симбиозе цели компании всё-таки важнее, чем цели отдельных сотрудников. Хорошая компания ценит и любит свои ресурсы, но с точки зрения бизнеса людей (как и многие другие ресурсы) всегда можно заменить (хоть иногда и очень сложно). А вот изменить глобальные цели – невозможно. Да и странно было бы ожидать это от бизнеса. «Давайте мы теперь вместо того, чтобы печь хлеб, будем давать музыкальные представления на детских утренниках!» Ради чего? Если ради большей прибыли и если это легко осуществить, давайте. Но менять направление бизнеса только потому, что пекарь Володя любит и хочет петь (иначе может уволиться), естественно, никто не станет.
Следовательно, первым и самым важным участником производственного процесса является сам бизнес. Он, образно говоря, платит и поэтому заказывает музыку. Чего хочет бизнес? Цели очень разные. Начиная с благотворительности и заканчивая трудоустройством родственника (бывает и так). Но всё же в большинстве случаев главной целью является улучшение благосостояния собственников. И желательно с наименьшими затратами. «Как можно меньше потратить и как можно больше заработать» – это азбука рынка.
В наших бизнес-процессах представителем бизнеса является менеджер по продажам, который сопровождает клиента на всех этапах использования сервиса проценки (совмещая в т.ч. в себе функции менеджера по ведению проекта, т.е. взаимодействую с разработчиками напрямую при появлении новых задач). Он призван цели бизнеса понять, сформулировать, донести до клиента, если потребуется, «разжевать», найти компромисс и всё грамотно спланировать. А затем – проконтролировать процесс, помочь в процессе эксплуатации.
Какие у него цели? Это очевидно: за как можно меньший период времени получить как можно больше клиентов. Чтобы и эксперименты провести, проверить идеи на жизнеспособность, и возможные недочёты в процессе внедрений успеть исправить, и как можно скорее начать зарабатывать деньги на произведённом продукте (я намеренно не говорю о качестве, но подразумеваю его: некачественный товар никто приобретать не будет).
Часто менеджер по продажам видит проблемы клиентов и ставит соответствующие задачи в отдел разработки. Т.к. он проявляет лояльность и интерес к конечной продажи, то он требует постоянно данные о сроках, обзор текущей ситуации, давит на остальных участников процесса и, кажется, хочет всё и сразу. Он просто хочет понимать, как сделать максимально эффективно, а в идеале – как в следующий раз сделать ещё больше и ещё быстрее. Это нормально и с точки зрения бизнеса хорошо.
Следовательно, нам необходимо важность целей менеджера донести до всех участников процесса, объяснить – и, возможно, тогда менеджеру не придётся бегать за разработчиком каждые полчаса, вопрошая: «Ну, когда уже будет готово?!», мешая ему и отвлекая от работы над задачей.
Идеально было бы, если бы все члены команды понимали важность процесса, были хорошо мотивированы и аккуратны и всегда всё успевали. Возможно ли это? Не всегда. Особенно если говорить об объяснении и разделении общих ценностей. Но уверен, что всегда можно найти компромисс, если сделать так, чтобы последующие участники процесса сами стремились уложиться в срок, ориентируясь на какой-нибудь простой показатель и руководствуясь простыми правилами.
В нашей компании таким показателем является Due date. Как мы при этом добиваемся, чтобы все члены команды сами стремились к достижению целей бизнеса, я расскажу дальше.
Кто у нас следующий участник процесса? Пекарь Володя. В нашем случае – программист. Какие цели могут быть у обычного человека, даже если учитывать, что средний IQ в нашей отрасли высокий? Заработать денег и уехать на Бали, купить квартиру, накопить на старость, выплатить кредит, купить гитару Gibson, уйти пораньше с работы, сходить вечером в кино и познакомиться с симпатичной соседкой. Так и быть, поскольку речь об айтишниках, накинем ещё: разобрать беклог на работе, воспроизвести надоевший баг и избавиться от придирок начальника, изучить Erlang, «пощупать» новый фреймворк для Python, выучить английский, собрать дрон на Raspberry Pi и дослушать подкаст про преимущества Kotlin.
Разумеется, есть отличные ребята, которые «болеют за проект» и «понимают бизнес», – ведь мы вместе работаем над общим делом. Но попробуйте им несколько раз не заплатить зарплату (я не пытаюсь обидеть – я специально играю на контрастах, чтобы была понятна суть). Что получится в итоге? Они уйдут в Яндекс, Facebook, Google и любую другую компанию, где зарплаты немаленькие, кормят обедами, стригут и делают массаж и маникюр. И правильно сделают! Работа – это место, где бизнес покупает труд (и мозги) программистов за деньги, поэтому тут правят товарно-денежные отношения. И если у бизнеса цель – получить как можно больше работы за наименьшие деньги, то у сотрудников цель противоположная: сделать как можно меньше и получить за это как можно больше.
Разумеется, в процессе есть и другие участники: дизайнеры, копирайтеры, аналитики, тестировщики, релиз-инженеры, сисадмины. Но во-первых, их цели не сильно отличаются от целей пекаря Володи. А во-вторых, они часто выступают не на передовых ролях, а скорее прикрывают бойцов-разработчиков, пока те «идут в атаку». Кстати, таких сотрудников в компании вообще может не быть: их роли часто совмещаются с другими ролями.
Итак, основной участник процесса после менеджера, представляющего бизнес, – программист. Пекарь Володя может делать много, если ему интересно; он может ночами не спать, не есть, не выходить на улицу. Но задачи у бизнеса разные, и среди них немало неинтересных и рутинных. Так что, если Володя выполнил десять интересных для себя, но неактуальных для бизнеса задач и одну неинтересную, но очень важную для бизнеса – это равносильно тому, что он выполнил только одну задачу. Бизнесу важно, чтобы произведённый товар был ликвиден и конкурентоспособен, а какие технологии при этом использовались, как удачно Володя применил алгоритмы и паттерны хлебопечения – вопрос второстепенный.
Конечно, Володе не хочется знать ни про какие дедлайны, не хочется общаться с менеджером, дизайнерами, бухгалтерами – ему хочется сесть и погрузиться в свою интересную задачу (и чтобы никто не мешал). И в этих условиях сроки, планы, заказчики, конкуренты – это суровая реальность, с которой Володя вынужден мириться, но не часть стратегической цели, как в случае с продакт-менеджером.
Ответственность
Как сделать так, чтобы цели компании, которые так далеки от целей пекаря Володи, всё-таки учитывались в процессе разработки? Чтобы на всех этапах при множестве подводных камней, проблем и неожиданностей, принимались такие решения, которые полезны в первую очередь компании? Чтобы Володе было необходимо соблюсти дедлайн и в идеале избежать при этом проблем с планированием архитектуры, оверинжинирингом и других, которые могут увести его в сторону от потребностей бизнеса?
Мы в Майсапп называем такой процесс «ответственностью разработчика» и всячески стимулируем и поощряем эту самую ответственность. Что это означает, как мы это стимулируем? Очень просто: за соблюдение срока (того самого Due date) отвечает разработчик.
Это значит, что и устанавливать срок должен сам разработчик. Разумеется, он должен сделать это, тщательно изучив задачу и стараясь учесть как можно больше факторов при планировании. И разумеется, он должен стремиться этот срок соблюсти. Но при этом нужно быть готовым к тому, что разработчик может сорвать дедлайн. Суть в том, как мы поступаем дальше: мы рассматриваем каждый нюанс, который мешает нам уложиться в срок, и готовим ответ на него (как сделать так, чтобы в следующий раз подобная проблема не повторилась).
Ответ надо требовать от разработчика, потому что он знает проект лучше всех. Он назвал срок в этот раз, и он назовёт его в будущем. Возможно, он снова ошибётся – это не страшно. Важно то, что такой подход совершенствует инженерную культуру и стимулирует рост разработчика и всей компании в целом. И очевидно, что решение о том, как избежать подобных проблем в будущем, должно быть надёжным. Не «постараться в следующий раз», а сделать так, чтобы это не повторилось, исключив по максимуму человеческий фактор.
Хорошо бы, чтобы технический менеджер, получив срок на реализацию (Due date) и подтвердив его, не перестал обращать внимание на проект до наступления дедлайна – это рискованно и откладывает решение многих проблем на последний этап (проблем, которые проще, быстрее и дешевле решить сразу). Тут необходимо с определённой, заранее оговорённой периодичностью (чтобы это не отвлекало разработчика от работы) возвращаться к каждой задаче и уточнять ситуацию, корректировать сроки. Возможно, придётся принимать компромиссные решения, позволяющие уложиться в срок, но на перспективу оставляющие «полировку» и доработки функционала.
Ну, и не лишним будет упомянуть, что просто накинуть n дней к сроку – не лучшее решение. Как это контролировать? Очень просто: задачи, выполненные раньше срока, тоже должны считаться неправильно спланированными. При этом «неправильно спланированные» не значит, что всё плохо и нужно наказать разработчика – это значит, что следует обратить на этот аспект внимание менеджера и обсудить проблемы, повлиявшие на срок (это могут быть, например, «творческий экстаз» и неожиданные находки в процессе разработки).
Разумеется, не забываем про Закон Паркинсона, который гласит, что работа занимает всё отпущенное на неё время. Но во-первых, самый действенный способ этому противодействовать – сократить время выполнения задачи, сделав что-то полезное до срока её завершения, что замечательно вписывается в разработку. Во-вторых, мы рассматриваем любое отклонение от срока как повод к ретроспективе и стимулированию выработки надёжного решения о том, как сделать более точный прогноз в будущем. А в-третьих, даже если мы уложились в сроки, нужно обязательно задать вопрос: как в следующий раз сделать быстрее?
Очень важно уловить суть – мы не стремимся просто заставить всех соблюдать Due date. В разработке (в отличие от хлебопечения) слишком много неопределённостей. Очень немногие задачи похожи одна на другую – это не «универсальные» батоны хлеба. Если у пекаря «что-то пошло не так» со сроками, значит, либо случился форс-мажор (отключили электричество, вовремя не привезли муку и т. д.), либо он просто лентяй. В разработке же, напротив, редко удаётся уложиться в установленный срок, даже если очень стараться. И если разработчик в срок не уложился, это совсем не значит, что он где-то схалтурил. Суть тут в другом – мы смотрим на то, почему сроки не выдержаны и оцениваем причины (что повлияло на срок: ситуация, ресурсы, лень исполнителей или непонимание бизнес-целей). Разработчик может быть очень работоспособным, но без нацеленности на результат постоянно отвлекаться на несущественные мелочи, которые могут показаться ему важными (или, как вариант, на оказание помощи грузчику Васе, потому что у них приятельские отношения). В результате у разработчика есть масса причин, которые он искренне считает важными, но при этом отсутствует результат. Тут необходима постоянная поддержка и корректировка менеджера.
Итак, подведём итог…
Разработчик устанавливает срок задачи в виде Due date. Это срок, когда задача окажется на продакшене.
Менеджер должен подтвердить срок Due date. Хорошо бы, чтобы он сделал это, предварительно самостоятельно изучив проект, и сразу указал на факторы, способные повлиять на сроки в будущем.
С определённой периодичностью, оговорённой заранее, менеджер должен проверять статус вместе с разработчиком: рассматривать проблемы, которые уже могли возникнуть, и процессы, которые уже можно ускорить. Пример: «Почему ревью трёх строк кода заняло три дня?»
После завершения проекта в любом случае нужно делать ретроспективу и ставить вопрос: как в следующий раз сделать быстрее?
Due date – это оптимистичный прогноз. В нашей компании все это понимают и знают, что разработчику нужна поддержка менеджера на всех этапах работы над проектом. И даже если предположить, что у разработчика остаётся небольшой запас времени, который помогает ему чувствовать себя спокойнее и увереннее, в этом нет ничего плохого. У нас цель – сделать эффективно и прагматично, а не «загнать лошадей насмерть», ведь нам ещё работать вместе и делать много крутых проектов.
Заключение
Создавая процесс, я стараюсь делать так, чтобы система сама себя оптимизировала. В теории решения изобретательских задач есть подход, который называется «идеальный конечный результат» (ИКР). Он предлагает при решении задачи представить себе идеальный образ решения, когда нужное действие совершается без каких-либо затрат, усложнений и нежелательных эффектов.
В разработке часто случается так, что мы требуем от разработчика чего-то, пытаемся это контролировать, окружаем себя всё большим и большим количеством показателей, чтобы получить уверенность в том, что всё идёт по плану. Но чем больше людей, чем больше задач, чем больше показателей, тем этим становится всё сложнее и сложнее управлять. В результате можно прийти к ситуации, когда времени нет ни на что, кроме таблиц с показателями и бесед, а дела всё равно идут не очень.
К тому же имеется масса факторов, влияющих на мотивацию разработчика, на стимуляцию его понимания и принятия целей бизнеса: перспективы бизнеса, понимание важности проекта для компании, стремление к беспроблемному внедрению и эксплуатации, субъективная удовлетворённость и т. д. Но многое из этого трудно формализовать и измерить. А тем более сложно порой донести ценность до конкретного исполнителя. Часто даже очень хороший разработчик не улавливает изменение направления «продуктового ветра», и ему требуется какой-то понятный и простой механизм, указывающий верное направление.
Соответственно, я рассматриваю Due date как один из основных инструментов стимулирования ИКР разработчика на всех этапах. Он проходит через весь процесс и заставляет изобретать решения, позволяющие избежать массу проблем в будущем. Он позволяет нам делегировать ответственность, не прибегая к многочисленным KPI. Он понятен и доступен практически всем. И он ведёт нас всех к главной цели бизнеса: сделать как можно быстрее как можно больше. А будет ли это ещё и дёшево, зависит от тех решений, которые мы будем использовать, а следовательно, от нас всех.
