Итак, вы решили дать миру новый программный продукт или сервис. У вас есть продуманная идея, видение, понятное позиционирование, несколько первых потенциальных клиентов и даже бюджет. В общем, дело за малым – собрать команду разработчиков и сделать продукт.
В этой статье мы рассмотрим правильные и неправильные решения при подборе людей, их мотивации и сохранении команды – вашего нового актива. Речь пойдет не о том, как набрать лучших людей и построить совершенную машину разработки, а о том, какие грубые ошибки в подборе людей и организации их работы могут погубить ваше начинание.
В идеальной ситуации разработка нового продукта выглядит так: вы набираете людей, описываете им ваш продукт так, как вы его видите, и называете срок. Команда уходит работать и в нужный момент приносит готовый качественный продукт, который потом понемногу (но также быстро и качественно) дорабатывает.
В жизни такое, конечно же, бывает нечасто. В каждом случае возникает свой набор проблем, но в целом они достаточно типичные. Поэтому еще на старте проекта можно описать набор самых распространенных рисков, некоторые из которых в ходе работы реализуются в распространенные же проблемы. Посмотрим самые часто реализующиеся из них:
Беда не приходит одна, и часто реализуется сразу несколько рисков. Например, бывает одновременно и фатальное затягивание сроков, и стабильно некачественный продукт, и трудоемкая реализация новых требований. Риск потери работоспособной команды в этом случае вряд ли реализуется, потому что ее тут и не было.
Или другая ситуация, когда продукт сделан быстро и качественно, хорошо решает определенную задачу клиентов. Но вот возникло желание добавить дополнительную функциональность, а в исходном решении заложились на то, что таких требований никогда не будет. Новые функции реализуются стройной системой костылей, долго и трудно. А потом ключевым специалистам все это надоедает, и они уходят.
Реализация любого из этих рисков и даже сочетания нескольких – не приговор для продукта и бизнеса. Как правило, можно приложить усилия и вернуть свой продукт на рельсы устойчивого развития. Особенно, если компания уже прилично зарабатывает. Но потраченные время и деньги не пойдут на развитие, клиенты будут все это время ждать решения своих проблем, и у конкурентов появится фора. Профилактика же намного дешевле лечения. Вот про нее и поговорим.
Любой разработчик (впрочем, это касается и других специалистов, вовлеченных в разработку) обладает двумя немного условными, но очень важными параметрами. Это квалификация и мотивация.
Квалификация описывает, насколько хорошо человек может делать свою работу. А мотивация определяет, насколько он действительно реализует эту свою способность.
Опишем четыре крайних случая:
Оба эти параметра не постоянны во времени.
Квалификация (если умудриться ее измерить некоторым хитрым числом) как правило растет изредка и скачкообразно – в периоды приобретения ценного опыта, освоения новых подходов и технологий. Но можно сказать, что она иногда падает. Например, при переходе на новую технологию, еще неизвестную разработчику, его квалификация именно в вашей команде слегка упадёт. А потом наоборот вырастет.
Мотивация же скачет вверх-вниз, как ненормальная. На нее влияет огромное количество факторов. Вера в продукт, обратная связь от пользователей и руководства, соотношение интересных и рутинных задач, несколько дней полного напряжения перед проблемным релизом, известие о том, что новый коллега на такой же должности получает в полтора раза больше, похвала от коллег – все это заставляет мотивацию колебаться в очень широких пределах. На практике очень трудно продержаться на пике продуктивности больше нескольких дней или поддерживать очень высокую среднюю мотивацию больше нескольких месяцев. Но зато на пике мотивации крутой разработчик может проделать работу, которая заложит фундамент вашего будущего продукта, или провести такую глубокую переработку, которая откроет вашему продукту новые возможности.
Говоря упрощенно, можно рассматривать результат работы и отдельного сотрудника, и всей команды как произведение квалификации на мотивацию. Околонулевое значение одного из параметров даст очень посредственный результат, а произведение больших величин позволяет создавать прорывные продукты.
Квалификацию можно разложить на нескольких составляющих:
С мотивацией тоже не все так просто. Можно сказать, что у нее есть некоторый базовый уровень, который определяется тем, верит ли человек в продукт, над которым работает, видит ли он перспективы для себя лично, ощущает ли, что в целом все идет, как надо.
Вокруг этого базового уровня мотивация каждый день колеблется в очень широких пределах. Но если базовый уровень слишком низкий, пиков продуктивности, позволяющих делать прорывной продукт, не будет совсем. А падения «в ноль», когда целый день проходит в борьбе с собой и в имитации деятельности, будет намного больше.
И наоборот, когда базовый уровень мотивации высок, общая эффективность сотрудников (особенно в части взаимодействия) будет намного выше. Падений «в ноль» избежать все равно не удастся (хотя бы из-за накопления усталости), но это не будет повседневным режимом.
Итак, у нас есть базовый уровень мотивации, который определяется долгосрочными параметрами, и «текущий», за которым нужно следить каждый день.
Все очень просто. Если вы хотите, чтобы ваш проект провалился не из-за проблем с разработкой, а на более позднем этапе (и тем более, если хотите, чтобы он выстрелил), нужно:
И так, нам нужны квалифицированные люди. То есть люди, которые не только технически подкованы и опытны, но еще и будут готовы продуктивно вместе работать. Где же их взять?
Набирайте людей с опытом и с прививкой правильной культуры. Обычно это люди с опытом 5+ лет, которые заметное время поработали в больших и средних компаниях, про которые вы знаете, что там все в порядке с культурой. Культура в нашем случае – это когда не принято ни при каких обстоятельствах делать говно (смиримся с тем, что это фактически общепринятая формулировка в нашей области), внутри команд царит атмосфера сотрудничества, компания и сотрудники открыты современным подходам к организации эффективной работы и так далее. В общем, почетная роль больших и средних IT-компаний – готовить вам сотрудников. А поскольку они достаточно большие, неплохие разработчики, которые застряли в профессиональном, карьерном или зарплатном росте, там обязательно будут. Вот они-то вам и нужны.
Наградой за правильный выбор будет команда, которая знает, что делает, вовлечена в процесс, прозрачна для бизнеса и делает с ним одно дело – годный продукт.
Нанимать в команду стратапа людей без опыта (вчерашних студентов, сегодняшних стажеров), людей из in-house разработки и из маленьких компаний, занимающихся заказной разработкой (если, конечно, у них нет опыта, описанного выше).
У них не будет либо опыта и кругозора, позволяющих принимать правильные решения (например, в части прогнозирования объемов данных, нагрузки, организации модульности и separation of concerns), либо культуры работы в эффективной команде (ответственности, навыков планирования и всякого agile, design and code review, тестирования и написания тестов, и так далее).
А еще неопытный разработчик будет учиться за ваш счет и приносить мало пользы, но при этом занимать место человека, который уже мог бы двигать ваше дело. Он будет пожирать время опытных разработчиков (вот отличная статья на Хабре, иллюстрирующая проблему), которым придется отвечать на вопросы, внимательно проверять код новичка, а потом за ним переделывать. А если не переделать, то плохое решение выстрелит гораздо позже, и переделка, которая стоила бы максимум несколько часов может потом обойтись в несколько дней, а то и недель.
Безусловно, бывают не такие редки счастливые исключения. Но если ваша цель – получить продукт в рамках срока и бюджета, то в первую очередь надо позаботиться о рисках, которые мы так подробно рассматривали в первой части статьи, а не рассчитывать на удачу.
Если вы выберете людей без подходящей технической квалификации, то можете обнаружить себя в ситуации, когда вчерашний студент в самом начале выбрал экзотическую СУБД вместо старого доброго SQL, а расходы на сериализацию в JSON оказались такими огромными, что приложение намертво встало. И вот уже три недели команда борется с проблемой устаревания информации в кэше, потому что это все равно быстрее, чем сменить хранилище. И снежный ком проблем продолжает нестись под гору.
А если вы выберете людей без подходящей культуры, то однажды узнаете, что разработчики вообще не проверяют только что написанный код сами, а сразу отдают в тестирование, откуда он им возвращается по три раза. И срок каждого релиза сдвигается на неделю. А потом, когда вы в очередной раз понимаете, что сроки релиза в опять куда-то уехали, и ваш бизнес уже под угрозой, вы внезапно узнаете, что существует задача, завершения которой все ждут, чтобы двинуться дальше. Но ей никто не занимается. И каждый говорит, что задача – не его. На этом фоне ситуация, когда у пока что немногочисленных клиентов после обновления в третий раз всплывает уже два раза исправленная ошибка, уже кажется мелочью.
Аутсорсинг разработки – это отличное решение, если ваш стартап провалится.
Вам не надо искать и нанимать людей, все компетенции уже подобраны, подрядчик испытан. Но его интерес заключается в том, чтобы зарабатывать деньги, а не делать для вас качественный продукт максимально эффективно, и каждая ошибка, которая ведет к переделкам в будущем – это не проблема для подрядчика, а дополнительные деньги (ведь главное закрыть текущий этап, так?). Но если продукт все равно обречен, это не страшно. А вот если продукт вдруг совершенно неожиданно становится прибыльным, то у подрядчика может возникнуть вопрос: а не слишком ли дёшевы его услуги, да и вообще, чей это на самом деле продукт.
Про то, что вы не в состоянии влиять на эффективность работы команды подрядчика, и не можете так просто сменить команду, если что-то идет не так, мы даже не будем дополнительно говорить.
Итак, команда квалифицированных людей набрана. Теперь нам нужно решить вторую часть задачи – добиться того, чтобы все эти люди хорошо работали. А значит, мы будем говорить о поддержании мотивации.
Упрощенно говоря, разработчик (тестировщик, дизайнер, интерфейсолог, верстальщик, тимлид) работает в одном из трех режимов: «самореализация», «работаю за зарплату», «жду, когда меня уволят». И абсолютно все люди переключаются между этими режимами базовой мотивации в разные периоды своей жизни.
В режиме самореализации человек работает над вашим проектом как над своим. Болеет за проект, поглядывает вперёд, а не только себе под ноги, помогает товарищам. Ну и чего греха таить, хочет втащить новую технологию, опробовать новый подход или переделать все с нуля. Но вообще, в этом состоянии любой член команды в разы продуктивнее, чем в двух остальных (тут мы предлагаем читателю ознакомиться с классическим трудом Фредерика Брукса «Мифический человеко-месяц», если он вдруг еще не знаком с ним). И команда в целом тоже может работать в этаком турборежиме. В этом случае команда даже подтягивает «выпадающих» участников до общего уровня. В определенных пределах, конечно.
В режиме «работаю за зарплату» тоже нет ничего совсем уж плохого, при наличии чувства ответственности. Человек не горит, но зато его продуктивность стабильна. Он делает только «от и до», но зато он делает «от и до» хорошо. И с чистой совестью уходит домой в шесть. В этом режиме человек может неплохо делать свою работу, но у него уже нет мотивации вглядываться в будущее, продумывать потенциальные проблемы, к которым приведет то или иное решение, а главное – всерьез бороться за то, чтобы решения принимались правильные, качество продукта было высоким, а темп разработки отвечал нуждам бизнеса.
Ну и наконец, последний режим. Обычно человек падает в яму «жду, когда меня уже наконец уволят», когда у него кончаются и силы, и надежда на то, что все изменится к лучшему. Вероятно, в этом состоянии бывал каждый читатель, и описывать уровень продуктивности такого сотрудника нет никакой нужды.
Важно, чтобы команда как можно больше времени проводила в состоянии максимальной продуктивности и ни в коем случае не ушла в минус, откуда вы не сможете ее вытащить. Цена вопроса – шанс попадания в окно возможностей для бизнеса с конкурентоспособным продуктом.
Давайте поймем, как этого добиться.
Наша цель – собрать опытных разработчиков (тестировщиков, дизайнеров, верстальщиков, аналитиков) из крупных и средних IT-компаний, с опытом и высоким уровнем «производственной культуры». А потом поддерживать у них максимально эффективный режим работы.
Нужные люди идут к вам в офис «пообщаться», как правило, потому что на нынешней работе попали в профессиональный, карьерный, зарплатный тупик. То есть им не хватает веры в продукт, интересных задач, большей сферы полномочий и роста заработной платы. А еще всем хочется, чтобы их ценили, уважали и не кидали.
Если вам нужны эти люди, предложите им то, чего не хватает им.
Конечно, у каждого свой немного особенный запрос. И касается он не только момента найма, но и каждого следующего дня работы в этом проекте. Поэтому продумать условия для команды лучше задолго до того, как первый человек придет с вами познакомиться поближе. И не только продумать, но и наложить на бюджет и бизнес-план.
Итак, что вы можете предложить вашей будущей команде:
Начните с перспектив продукта. Мы же предполагаем, что у вас уже есть продуманная идея, видение и всё такое. Если вы хотите, чтобы ваша команда работала в режиме «самореализации», продайте ей ваш продукт. Никто не делает с энтузиазмом заведомое УГ.
Но продать ваш продукт один раз недостаточно. Ценность, значимость, успешность и перспективы продукта, его успехи и неудачи обязательно должны быть на виду. Если команда не видит прогресса, успехов и неудач, она никогда не будет ассоциировать себя с этим продуктом, и о режиме «самореализации» можно забыть. Все будут заняты только тем, чтобы не подставить свою личную задницу при очередной чрезвычайной ситуации.
После того, как продукт будущему члену команды продан, предложите хорошие денежные и социально-трудовые условия.
Вы забираете к себе опытных профессионалов, поэтому зарплата (с учетом премий) должна быть выше рыночной.
Во-первых, вы же забираете людей из таких компаний, которые выше среднего своим средним сотрудникам платить не хотят или не могут.
Во-вторых, вы говорите вашему сотруднику: «Мы понимаем ценность сотрудников, вы – наш ключевой актив, мы хотим и готовы платить нашим сотрудникам выше рынка (это важно для поддержания «режима самореализации») и при этом ожидаем, что они будут работать соответствующим образом. Мы не готовы платить меньше сотрудникам, которые работают хуже – мы не можем позволить себе таких сотрудников. И мы не можем платить больше, потому что такие расходы не позволят бизнесу взлететь».
В-третьих, достаточно высокие зарплаты позволяют, как было замечено выше, обоснованно требовать от сотрудника определенного уровня эффективности. Это станет важным, когда потребуется (а этот момент обязательно наступит, и не раз) изменить сложившиеся условия работы, изменить бизнес-процессы. Для всех, кого затронут изменения, это будет выход из зоны комфорта, поэтому без давления руководителя или извне команды дело не обойдется. Если изменения принесли пользу, умные люди в конце концов согласятся с ними, но без промежуточного конфликта все равно не обойтись. И в этом случае правильная материальная мотивация – важная страховка от потери ценных сотрудников.
Вопрос ответственности – ключевой в разработке программного обеспечения и для команды, и для бизнеса. Если объективно задача требует неделю рабочего времени, а руководитель требует решить ее за два дня и не слушает никаких аргументов, то в 99% случаев результатом будут плохо выполненные требования и горка заметенных под ковёр проблем. Разработчик будет вынужден сделать говно (мы помним, что специально набирали людей, которым делать говно физически неприятно), а проблемы, заметенные под ковер, обойдутся в часы или недели задержек в будущем. Мотивация упала, проблемы появились. Именно поэтому критически важно, чтобы оценка трудозатрат исходила от членов команды. За нее можно торговаться, формулировать задачу более детально, корректировать требования (привет, agile), но окончательную оценку должен дать человек, который будет ее выполнять. Потому что оценка задачи – это акт принятия на себя ответственности за сроки и качество решения этой задачи. Правильность оценки требует опыта, а взятие на себе ответственности требует культуры. Именно эти требования к членам команды мы и сформулировали во второй части статьи.
Фрустрация – это зазор между ожиданиями и реальностью. Всегда держите руку на пульсе ожиданий ваших профессионалов и смотрите, как обстоит дело в реальности.
Например, задержка зарплаты без предупреждения всего на день – минус в «мотивационную» карму. Внезапное изменение требований по средине итерации без понятных веских причин? Минус в карму. Коллега получает столько же, сколько ты, но работает вполсилы, и никто ничего не делает уже два месяца? Минус в карму. Нового сотрудника такого же уровня берут на такую же позицию с зарплатой в полтора раза выше? Все равно это станет известно – минус в карму. Всегда прощали просроченный на день дедлайн, а в этот раз строго в соответствии с договоренностью уменьшили премию? А всё равно минус в карму. Обещали премию на четких условиях, а потом «объективно, нет денег, чтобы столько заплатить»? Вам этого не забудут.
Минусов в карму избежать нельзя. Некоторые из них будут намеренными и абсолютно необходимыми. Но в какой-то момент накопление фрустрации приведет к скачкообразному падению продуктивность членов команды. А потом в какой-то критической точке упадет мотивация команды как таковой, и команда потянет мотивацию своих «заблудших» членов уже не вверх, а вниз. Поэтому очень важно следить за размером пропасти между ожиданиями и реальностью.
Просто не относитесь к команде разработки как одному из самых ценных активов.
Не «отчитывайтесь» перед командой. Ведь если подумать, то какое разработчикам дело до того, как идут продажи? Держите обсуждаемые с клиентами новые функции в секрете от команды до последнего. Заодно всегда в два раза уменьшайте для команды сроки появления функций, которые вы согласовали с клиентами.
Примите идеологию «умри, но сделай» в вопросах оценки сроков. Свалите вопрос мониторинга и поддержания мотивации на тимлида, это его работа. Не выполняйте обещаний, не извиняйтесь за задержку зарплаты и не увольняйте «загнивших» сотрудников. Ну и конечно примите как данность, что у сотрудников есть только один интерес – заработать побольше (ваших, между прочим) денег, делая поменьше работы.
Конечно же, разработка будет при всем этом работать, и продукт будет постепенно появляться. Но за одно и то же время будет сделано намного меньше функциональности, пользовательский опыт может оказаться критически плохим, а в тот момент, когда продукт неожиданно взлетает, окажется, что бежать в нужном темпе команда не может, в том числе из-за самостоятельно разложенных в коде граблей.
Поставьте высокую планку. Набирайте опытных специалистов, умеющих работать в команде. Точно знайте свои финансовые и временные возможности. Продайте команде свой продукт. Обеспечьте хорошие условия. Дайте людям возможность считать продукт вашим общим. Помните, что ответственность – не справка, ее не выдают, а берут своими руками. Следите за ожиданиями и действительностью. Используйте высокую мотивацию команды, чтобы получить конкурентоспособный продукт. И помните, что теперь у вас есть очень ценный актив, который не менее важен и не менее хрупок, чем доверие клиентов и интерес инвесторов.
В следующей статье мы рассмотрим вопросы организации работы команды – тоже с позиции минимизации рисков. Не переключайтесь.
В этой статье мы рассмотрим правильные и неправильные решения при подборе людей, их мотивации и сохранении команды – вашего нового актива. Речь пойдет не о том, как набрать лучших людей и построить совершенную машину разработки, а о том, какие грубые ошибки в подборе людей и организации их работы могут погубить ваше начинание.
Часть I. Риски
В идеальной ситуации разработка нового продукта выглядит так: вы набираете людей, описываете им ваш продукт так, как вы его видите, и называете срок. Команда уходит работать и в нужный момент приносит готовый качественный продукт, который потом понемногу (но также быстро и качественно) дорабатывает.
В жизни такое, конечно же, бывает нечасто. В каждом случае возникает свой набор проблем, но в целом они достаточно типичные. Поэтому еще на старте проекта можно описать набор самых распространенных рисков, некоторые из которых в ходе работы реализуются в распространенные же проблемы. Посмотрим самые часто реализующиеся из них:
- Фатальное затягивание сроков. Продукт разрабатывается и даже получается качественным, только вот либо окно возможностей закрылось, либо бюджет закончился.
- Стабильно некачественный продукт. Продукт готов и выпущен, клиенты пришли, но они постоянно сталкиваются с проблемами при использовании вашего продукта. А команда неделя за неделей, месяц за месяцем не может обеспечить им нормальную работу. Клиенты не выдерживают и уходят – либо к конкурентам, либо в никуда.
- Трудоемкая реализация новых требований. Клиенты стоят в очереди (некоторые – даже с пачкой денег) с просьбами добавить новые возможности, но почему-то доработка происходит очень-очень медленно. Или на серьезных объемах пользовательских данных через год после старта все вдруг стало работать очень-очень медленно, и никто не знает, как быстро решить проблему (а клиенты ругают вас последними словами и уходят). В общем, речь идет о низком «внутреннем качестве» вашего продукта: неудачная архитектура, отсутствие тестов на критические блоки кода, сложные внутренние зависимости – все это не позволяет с приемлемой скоростью развивать продукт и бороться за клиентов.
- Потеря работоспособной команды. В какой-то момент ключевые специалисты (особенно, если такой специалист один) могут внезапно решить, что им интереснее работать в другой компании, а то и вовсе попасть под трамвай. Бывает, что оставшаяся команда оказывается не в состоянии не только развивать, но и даже поддерживать продукт с приемлемым качеством. А кандидаты на собеседовании смотрят в полные тоски глаза потенциальных коллег, потом в код, и больше не выходят на связь.
Беда не приходит одна, и часто реализуется сразу несколько рисков. Например, бывает одновременно и фатальное затягивание сроков, и стабильно некачественный продукт, и трудоемкая реализация новых требований. Риск потери работоспособной команды в этом случае вряд ли реализуется, потому что ее тут и не было.
Или другая ситуация, когда продукт сделан быстро и качественно, хорошо решает определенную задачу клиентов. Но вот возникло желание добавить дополнительную функциональность, а в исходном решении заложились на то, что таких требований никогда не будет. Новые функции реализуются стройной системой костылей, долго и трудно. А потом ключевым специалистам все это надоедает, и они уходят.
Реализация любого из этих рисков и даже сочетания нескольких – не приговор для продукта и бизнеса. Как правило, можно приложить усилия и вернуть свой продукт на рельсы устойчивого развития. Особенно, если компания уже прилично зарабатывает. Но потраченные время и деньги не пойдут на развитие, клиенты будут все это время ждать решения своих проблем, и у конкурентов появится фора. Профилактика же намного дешевле лечения. Вот про нее и поговорим.
Часть II. Квалификация и мотивация
Любой разработчик (впрочем, это касается и других специалистов, вовлеченных в разработку) обладает двумя немного условными, но очень важными параметрами. Это квалификация и мотивация.
Квалификация описывает, насколько хорошо человек может делать свою работу. А мотивация определяет, насколько он действительно реализует эту свою способность.
Опишем четыре крайних случая:
- Высочайшая квалификация, зашкаливающая мотивация. Это неостановимый Творец. Он эффективен и лаконичен. Всегда знает, что делает, потому что все это уже делал. Работает сутки напролёт, потому что его вставило.
- Высочайшая квалификация, мотивация ушла в минус. Тоже всемогущ, только ему ничего не нужно. Кое-как решает срочные задачи, но надо заставлять и контролировать.
- Никакой квалификации и никакой мотивации. Стереотипный студент с профильным образованием, который на входе в профессию хочет большую зарплату, но поработать за нее только два месяца в году.
- Никакая квалификация, но зашкаливающая мотивация. Человек безумно энергичен, осваивает новое и учится. Но за ваш счет. Совершает всевозможные ошибки, часть из которых проявляется немедленно, а часть выстрелит потом. Пожирает время более опытных коллег (если они есть) вопросами, контролем и исправлением своих ошибок.
Оба эти параметра не постоянны во времени.
Квалификация (если умудриться ее измерить некоторым хитрым числом) как правило растет изредка и скачкообразно – в периоды приобретения ценного опыта, освоения новых подходов и технологий. Но можно сказать, что она иногда падает. Например, при переходе на новую технологию, еще неизвестную разработчику, его квалификация именно в вашей команде слегка упадёт. А потом наоборот вырастет.
Мотивация же скачет вверх-вниз, как ненормальная. На нее влияет огромное количество факторов. Вера в продукт, обратная связь от пользователей и руководства, соотношение интересных и рутинных задач, несколько дней полного напряжения перед проблемным релизом, известие о том, что новый коллега на такой же должности получает в полтора раза больше, похвала от коллег – все это заставляет мотивацию колебаться в очень широких пределах. На практике очень трудно продержаться на пике продуктивности больше нескольких дней или поддерживать очень высокую среднюю мотивацию больше нескольких месяцев. Но зато на пике мотивации крутой разработчик может проделать работу, которая заложит фундамент вашего будущего продукта, или провести такую глубокую переработку, которая откроет вашему продукту новые возможности.
Говоря упрощенно, можно рассматривать результат работы и отдельного сотрудника, и всей команды как произведение квалификации на мотивацию. Околонулевое значение одного из параметров даст очень посредственный результат, а произведение больших величин позволяет создавать прорывные продукты.
Чуть подробнее о квалификации
Квалификацию можно разложить на нескольких составляющих:
- Техническая квалификация – это знание своих инструментов (алгоритмов, языков, платформ и сред разработки, кучи фреймворков и библиотек, приложений для работы дизайнера или тестировщика и так далее), а также навыки их эффективного применения.
- Опыт – это знание о том, как нужно действовать в тех или иных ситуациях. Его можно получать на своих ошибках (например, когда разработчик сам написал несколько многопоточных приложений и наступил на все основные грабли) или на чужих (например, поработать в команде высоконагруженного решения и вблизи увидеть, как эти ошибки делают другие). Ценность опыта – в возможности на пути к цели избежать ошибок, которые могут дорого обойтись вашему продукту и бизнесу.
- Навыки взаимодействия – это умение эффективно выстраивать взаимодействие с окружающими: коллегами, пользователями, клиентами. Сюда входит и умение ясно формулировать мысли, и атмосфера взаимопомощи в команде, и ответственность за качество своей работы, и забота о конечных пользователях, и способность настоять на своем, если потребуется. Такую квалификацию, пожалуй, приобрести труднее всего. Наверное, поэтому ее часто называют культурой.
Чуть подробнее о мотивации
С мотивацией тоже не все так просто. Можно сказать, что у нее есть некоторый базовый уровень, который определяется тем, верит ли человек в продукт, над которым работает, видит ли он перспективы для себя лично, ощущает ли, что в целом все идет, как надо.
Вокруг этого базового уровня мотивация каждый день колеблется в очень широких пределах. Но если базовый уровень слишком низкий, пиков продуктивности, позволяющих делать прорывной продукт, не будет совсем. А падения «в ноль», когда целый день проходит в борьбе с собой и в имитации деятельности, будет намного больше.
И наоборот, когда базовый уровень мотивации высок, общая эффективность сотрудников (особенно в части взаимодействия) будет намного выше. Падений «в ноль» избежать все равно не удастся (хотя бы из-за накопления усталости), но это не будет повседневным режимом.
Итак, у нас есть базовый уровень мотивации, который определяется долгосрочными параметрами, и «текущий», за которым нужно следить каждый день.
Так чего же мы хотим от сотрудников и команды?
Все очень просто. Если вы хотите, чтобы ваш проект провалился не из-за проблем с разработкой, а на более позднем этапе (и тем более, если хотите, чтобы он выстрелил), нужно:
- На все позиции набирать только людей достаточной квалификации;
- Обеспечить им высокую базовую мотивацию;
- Каждый день контролировать текущую мотивацию.
Часть III. Выбор людей. Правильно и неправильно
И так, нам нужны квалифицированные люди. То есть люди, которые не только технически подкованы и опытны, но еще и будут готовы продуктивно вместе работать. Где же их взять?
Как правильно
Набирайте людей с опытом и с прививкой правильной культуры. Обычно это люди с опытом 5+ лет, которые заметное время поработали в больших и средних компаниях, про которые вы знаете, что там все в порядке с культурой. Культура в нашем случае – это когда не принято ни при каких обстоятельствах делать говно (смиримся с тем, что это фактически общепринятая формулировка в нашей области), внутри команд царит атмосфера сотрудничества, компания и сотрудники открыты современным подходам к организации эффективной работы и так далее. В общем, почетная роль больших и средних IT-компаний – готовить вам сотрудников. А поскольку они достаточно большие, неплохие разработчики, которые застряли в профессиональном, карьерном или зарплатном росте, там обязательно будут. Вот они-то вам и нужны.
Наградой за правильный выбор будет команда, которая знает, что делает, вовлечена в процесс, прозрачна для бизнеса и делает с ним одно дело – годный продукт.
Как неправильно
Нанимать в команду стратапа людей без опыта (вчерашних студентов, сегодняшних стажеров), людей из in-house разработки и из маленьких компаний, занимающихся заказной разработкой (если, конечно, у них нет опыта, описанного выше).
У них не будет либо опыта и кругозора, позволяющих принимать правильные решения (например, в части прогнозирования объемов данных, нагрузки, организации модульности и separation of concerns), либо культуры работы в эффективной команде (ответственности, навыков планирования и всякого agile, design and code review, тестирования и написания тестов, и так далее).
А еще неопытный разработчик будет учиться за ваш счет и приносить мало пользы, но при этом занимать место человека, который уже мог бы двигать ваше дело. Он будет пожирать время опытных разработчиков (вот отличная статья на Хабре, иллюстрирующая проблему), которым придется отвечать на вопросы, внимательно проверять код новичка, а потом за ним переделывать. А если не переделать, то плохое решение выстрелит гораздо позже, и переделка, которая стоила бы максимум несколько часов может потом обойтись в несколько дней, а то и недель.
Безусловно, бывают не такие редки счастливые исключения. Но если ваша цель – получить продукт в рамках срока и бюджета, то в первую очередь надо позаботиться о рисках, которые мы так подробно рассматривали в первой части статьи, а не рассчитывать на удачу.
Что бывает за неправильный выбор
Если вы выберете людей без подходящей технической квалификации, то можете обнаружить себя в ситуации, когда вчерашний студент в самом начале выбрал экзотическую СУБД вместо старого доброго SQL, а расходы на сериализацию в JSON оказались такими огромными, что приложение намертво встало. И вот уже три недели команда борется с проблемой устаревания информации в кэше, потому что это все равно быстрее, чем сменить хранилище. И снежный ком проблем продолжает нестись под гору.
А если вы выберете людей без подходящей культуры, то однажды узнаете, что разработчики вообще не проверяют только что написанный код сами, а сразу отдают в тестирование, откуда он им возвращается по три раза. И срок каждого релиза сдвигается на неделю. А потом, когда вы в очередной раз понимаете, что сроки релиза в опять куда-то уехали, и ваш бизнес уже под угрозой, вы внезапно узнаете, что существует задача, завершения которой все ждут, чтобы двинуться дальше. Но ей никто не занимается. И каждый говорит, что задача – не его. На этом фоне ситуация, когда у пока что немногочисленных клиентов после обновления в третий раз всплывает уже два раза исправленная ошибка, уже кажется мелочью.
Особый случай – аутсорсинг разработки
Аутсорсинг разработки – это отличное решение, если ваш стартап провалится.
Вам не надо искать и нанимать людей, все компетенции уже подобраны, подрядчик испытан. Но его интерес заключается в том, чтобы зарабатывать деньги, а не делать для вас качественный продукт максимально эффективно, и каждая ошибка, которая ведет к переделкам в будущем – это не проблема для подрядчика, а дополнительные деньги (ведь главное закрыть текущий этап, так?). Но если продукт все равно обречен, это не страшно. А вот если продукт вдруг совершенно неожиданно становится прибыльным, то у подрядчика может возникнуть вопрос: а не слишком ли дёшевы его услуги, да и вообще, чей это на самом деле продукт.
Про то, что вы не в состоянии влиять на эффективность работы команды подрядчика, и не можете так просто сменить команду, если что-то идет не так, мы даже не будем дополнительно говорить.
Часть IV. Мотивация команды. Правильно и неправильно
Итак, команда квалифицированных людей набрана. Теперь нам нужно решить вторую часть задачи – добиться того, чтобы все эти люди хорошо работали. А значит, мы будем говорить о поддержании мотивации.
Упрощенно говоря, разработчик (тестировщик, дизайнер, интерфейсолог, верстальщик, тимлид) работает в одном из трех режимов: «самореализация», «работаю за зарплату», «жду, когда меня уволят». И абсолютно все люди переключаются между этими режимами базовой мотивации в разные периоды своей жизни.
В режиме самореализации человек работает над вашим проектом как над своим. Болеет за проект, поглядывает вперёд, а не только себе под ноги, помогает товарищам. Ну и чего греха таить, хочет втащить новую технологию, опробовать новый подход или переделать все с нуля. Но вообще, в этом состоянии любой член команды в разы продуктивнее, чем в двух остальных (тут мы предлагаем читателю ознакомиться с классическим трудом Фредерика Брукса «Мифический человеко-месяц», если он вдруг еще не знаком с ним). И команда в целом тоже может работать в этаком турборежиме. В этом случае команда даже подтягивает «выпадающих» участников до общего уровня. В определенных пределах, конечно.
В режиме «работаю за зарплату» тоже нет ничего совсем уж плохого, при наличии чувства ответственности. Человек не горит, но зато его продуктивность стабильна. Он делает только «от и до», но зато он делает «от и до» хорошо. И с чистой совестью уходит домой в шесть. В этом режиме человек может неплохо делать свою работу, но у него уже нет мотивации вглядываться в будущее, продумывать потенциальные проблемы, к которым приведет то или иное решение, а главное – всерьез бороться за то, чтобы решения принимались правильные, качество продукта было высоким, а темп разработки отвечал нуждам бизнеса.
Ну и наконец, последний режим. Обычно человек падает в яму «жду, когда меня уже наконец уволят», когда у него кончаются и силы, и надежда на то, что все изменится к лучшему. Вероятно, в этом состоянии бывал каждый читатель, и описывать уровень продуктивности такого сотрудника нет никакой нужды.
Важно, чтобы команда как можно больше времени проводила в состоянии максимальной продуктивности и ни в коем случае не ушла в минус, откуда вы не сможете ее вытащить. Цена вопроса – шанс попадания в окно возможностей для бизнеса с конкурентоспособным продуктом.
Давайте поймем, как этого добиться.
Как правильно
Наша цель – собрать опытных разработчиков (тестировщиков, дизайнеров, верстальщиков, аналитиков) из крупных и средних IT-компаний, с опытом и высоким уровнем «производственной культуры». А потом поддерживать у них максимально эффективный режим работы.
Нужные люди идут к вам в офис «пообщаться», как правило, потому что на нынешней работе попали в профессиональный, карьерный, зарплатный тупик. То есть им не хватает веры в продукт, интересных задач, большей сферы полномочий и роста заработной платы. А еще всем хочется, чтобы их ценили, уважали и не кидали.
Если вам нужны эти люди, предложите им то, чего не хватает им.
Конечно, у каждого свой немного особенный запрос. И касается он не только момента найма, но и каждого следующего дня работы в этом проекте. Поэтому продумать условия для команды лучше задолго до того, как первый человек придет с вами познакомиться поближе. И не только продумать, но и наложить на бюджет и бизнес-план.
Итак, что вы можете предложить вашей будущей команде:
Вовлечение в продукт
Начните с перспектив продукта. Мы же предполагаем, что у вас уже есть продуманная идея, видение и всё такое. Если вы хотите, чтобы ваша команда работала в режиме «самореализации», продайте ей ваш продукт. Никто не делает с энтузиазмом заведомое УГ.
Но продать ваш продукт один раз недостаточно. Ценность, значимость, успешность и перспективы продукта, его успехи и неудачи обязательно должны быть на виду. Если команда не видит прогресса, успехов и неудач, она никогда не будет ассоциировать себя с этим продуктом, и о режиме «самореализации» можно забыть. Все будут заняты только тем, чтобы не подставить свою личную задницу при очередной чрезвычайной ситуации.
Деньги
После того, как продукт будущему члену команды продан, предложите хорошие денежные и социально-трудовые условия.
Вы забираете к себе опытных профессионалов, поэтому зарплата (с учетом премий) должна быть выше рыночной.
Во-первых, вы же забираете людей из таких компаний, которые выше среднего своим средним сотрудникам платить не хотят или не могут.
Во-вторых, вы говорите вашему сотруднику: «Мы понимаем ценность сотрудников, вы – наш ключевой актив, мы хотим и готовы платить нашим сотрудникам выше рынка (это важно для поддержания «режима самореализации») и при этом ожидаем, что они будут работать соответствующим образом. Мы не готовы платить меньше сотрудникам, которые работают хуже – мы не можем позволить себе таких сотрудников. И мы не можем платить больше, потому что такие расходы не позволят бизнесу взлететь».
Лично автору кажется, что с правильными людьми лучше играть в открытую: обозначить окладно-премиально-шоколадные условия на все позиции, количество этих позиций, на сколько месяцев хватит бюджета, и как планируется добывать (зарабатывать или инвестировать) деньги. Это снимает ненужные ожидания по поводу роста зарплаты по мере роста в должности, размеров премий, пересмотра зарплат до того, как продукт начал приносить деньги, и все такое.
Заодно сразу же закроем вопрос о том, нужно ли предлагать долю в бизнесе. Так сложилось, что ситуация в России отличается от ситуации в США в этом вопросе очень сильно. Там стартапы не могут конкурировать в плане денег с крупнейшими компаниями отрасли, зато предлагают мечту – опционы на случай взлёта. У нас все ровно наоборот – стартапы с бюджетом и продуманным планом развития за счет маленькой эффективной команды могут позволить себе платить немного больше рынка. А на обещания доли в светлом будущем никого не купишь: слишком уж печальная статистика. При этом предлагать долю в бизнесе людям, с которыми еще не сварено каши, в России элементарно опасно: корпоративный конфликт на любом этапе может похоронить всё начинание. Опционы же у нас пока толком не работают.
В-третьих, достаточно высокие зарплаты позволяют, как было замечено выше, обоснованно требовать от сотрудника определенного уровня эффективности. Это станет важным, когда потребуется (а этот момент обязательно наступит, и не раз) изменить сложившиеся условия работы, изменить бизнес-процессы. Для всех, кого затронут изменения, это будет выход из зоны комфорта, поэтому без давления руководителя или извне команды дело не обойдется. Если изменения принесли пользу, умные люди в конце концов согласятся с ними, но без промежуточного конфликта все равно не обойтись. И в этом случае правильная материальная мотивация – важная страховка от потери ценных сотрудников.
Ответственность
Вопрос ответственности – ключевой в разработке программного обеспечения и для команды, и для бизнеса. Если объективно задача требует неделю рабочего времени, а руководитель требует решить ее за два дня и не слушает никаких аргументов, то в 99% случаев результатом будут плохо выполненные требования и горка заметенных под ковёр проблем. Разработчик будет вынужден сделать говно (мы помним, что специально набирали людей, которым делать говно физически неприятно), а проблемы, заметенные под ковер, обойдутся в часы или недели задержек в будущем. Мотивация упала, проблемы появились. Именно поэтому критически важно, чтобы оценка трудозатрат исходила от членов команды. За нее можно торговаться, формулировать задачу более детально, корректировать требования (привет, agile), но окончательную оценку должен дать человек, который будет ее выполнять. Потому что оценка задачи – это акт принятия на себя ответственности за сроки и качество решения этой задачи. Правильность оценки требует опыта, а взятие на себе ответственности требует культуры. Именно эти требования к членам команды мы и сформулировали во второй части статьи.
Ожидания и реальность
Фрустрация – это зазор между ожиданиями и реальностью. Всегда держите руку на пульсе ожиданий ваших профессионалов и смотрите, как обстоит дело в реальности.
Например, задержка зарплаты без предупреждения всего на день – минус в «мотивационную» карму. Внезапное изменение требований по средине итерации без понятных веских причин? Минус в карму. Коллега получает столько же, сколько ты, но работает вполсилы, и никто ничего не делает уже два месяца? Минус в карму. Нового сотрудника такого же уровня берут на такую же позицию с зарплатой в полтора раза выше? Все равно это станет известно – минус в карму. Всегда прощали просроченный на день дедлайн, а в этот раз строго в соответствии с договоренностью уменьшили премию? А всё равно минус в карму. Обещали премию на четких условиях, а потом «объективно, нет денег, чтобы столько заплатить»? Вам этого не забудут.
Минусов в карму избежать нельзя. Некоторые из них будут намеренными и абсолютно необходимыми. Но в какой-то момент накопление фрустрации приведет к скачкообразному падению продуктивность членов команды. А потом в какой-то критической точке упадет мотивация команды как таковой, и команда потянет мотивацию своих «заблудших» членов уже не вверх, а вниз. Поэтому очень важно следить за размером пропасти между ожиданиями и реальностью.
Как неправильно
Просто не относитесь к команде разработки как одному из самых ценных активов.
А дело всегда может обернуться так, что исходная идея и самый первый продукт и его клиенты не могут приносить деньги, и нужно срочно переобуваться на лету. В этот момент из всех активов у вас останутся только деньги, воля основателей и команда разработки.
Не «отчитывайтесь» перед командой. Ведь если подумать, то какое разработчикам дело до того, как идут продажи? Держите обсуждаемые с клиентами новые функции в секрете от команды до последнего. Заодно всегда в два раза уменьшайте для команды сроки появления функций, которые вы согласовали с клиентами.
Примите идеологию «умри, но сделай» в вопросах оценки сроков. Свалите вопрос мониторинга и поддержания мотивации на тимлида, это его работа. Не выполняйте обещаний, не извиняйтесь за задержку зарплаты и не увольняйте «загнивших» сотрудников. Ну и конечно примите как данность, что у сотрудников есть только один интерес – заработать побольше (ваших, между прочим) денег, делая поменьше работы.
Конечно же, разработка будет при всем этом работать, и продукт будет постепенно появляться. Но за одно и то же время будет сделано намного меньше функциональности, пользовательский опыт может оказаться критически плохим, а в тот момент, когда продукт неожиданно взлетает, окажется, что бежать в нужном темпе команда не может, в том числе из-за самостоятельно разложенных в коде граблей.
Самое главное в один абзац
Поставьте высокую планку. Набирайте опытных специалистов, умеющих работать в команде. Точно знайте свои финансовые и временные возможности. Продайте команде свой продукт. Обеспечьте хорошие условия. Дайте людям возможность считать продукт вашим общим. Помните, что ответственность – не справка, ее не выдают, а берут своими руками. Следите за ожиданиями и действительностью. Используйте высокую мотивацию команды, чтобы получить конкурентоспособный продукт. И помните, что теперь у вас есть очень ценный актив, который не менее важен и не менее хрупок, чем доверие клиентов и интерес инвесторов.
В следующей части
В следующей статье мы рассмотрим вопросы организации работы команды – тоже с позиции минимизации рисков. Не переключайтесь.
