понедельник, 14 декабря 2015 г.

Оптимальное распределение ресурсов команды по задачам продукта

Очень похоже на заблуждение для некоторых ситуаций. Или вот еще про микроскоп похожая поговорка есть...

В большом продукте может быть десяток разнообразных областей, каждая со своей важностью, своими задачами, своими технологиями и требованиями к знаниям/опыту. В такой ситуации вся команда продукта может проводить планирование и выделять Самые Важные Задачи Для Всего Продукта. Из всех задач. Потом сотрудники начинают их делать в порядке назначенной очередности.

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

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

Из вариантов остается промежуточный: убегать с одной области продукта в другую можно, но очень редко (время эффективной работы должно быть существенно больше времени на обучение нового сотрудника). И развитие каждой области должно быть постоянно поддержано ресурсами, достаточными для того, что бы эта область соответствовала изменениям в мире (с критерием результативности "действительно соответствует")..

Однако и этот вариант можно назвать неэфективным из-за постоянной поддержки на развитие каждой области: задачи в ней совсем не Самые Важные, однако ими постоянно кто-то занимается. Это широкий простор для амбициозного руководителя: "Я нашел где мы можем здорово сэкономить! Ура мне и премию!" Или для бюрократа "По принятой методологии должен быть список задач и все должны их делать в порядке приоритета! Я наладил такую работу, ура мне и премию!" Эффект от такого изменения заметен сразу: Самые Важные Задачи кто-то сразу начинает делать! Они уже не ждут своей очереди! Они уже в списке "Doing"! Премии получены, все воодушевлены и с уверенностью смотрят в будущее.

Но для продукта факт "раньше начали делать" не важен. Важно "закончили делать", "легко сопровождать", "легко использовать", "легко изучить", "соответствует ситуации в мире", "посоветую друзьям", "не жалею о выборе"... Это совсем другие цели со своими критериями достижения. Происходит переход на первый вариант с перескоками между областями, тормозами, ухудшением и восстановлением скорости работы за счет качества и другими плюшками...

Вот такой невеселый конец.