Целеполагание и сроки
Opened this issue · 7 comments
Было бы здорово узнать немного про то, как бизнесу ставить цели тимлиду и вообще какие бывают способы планирования и расчёта сроков
Например, в практике был OKR и CCPM (не очень зашло, возможно плохо приготовил), может у тебя есть чем поделиться из собственного опыта?
тема довольно-таки большая.
Если вкратце — то OKR и ССPM мне кажутся какими-то костылями, а не системами целеполагания.
Мне нравится подход "мы просто понимаем, для чего и в какое состояние мы должны привести систему и работаем над этим"
Если длиннее — напишу статью отдельную.
Ну и в рамках "нормальной" работы тимлид как бы заинтересован в "нормальной" работе сотрудников.
Экономически и этически оправданной. Получается, что он как бы сам заинтересован в таких свойствах его системы, что программисты при старте работы быстро входят в курс дела, не делают лишней (ненужной работы), не толкаются локтями в процессе, не уходят посреди проекта, и т.п.
Давай разберемся, про какие ты цели говоришь?
Бизнесовые цели, например, заработать X денег за год или запустить проект к Y дате.
Если конкретизировать, то интересует опыт планирования сроков разработки. Понимаю, что, более или менее, точно можно планировать максимум на 2 недели, а вот как планировать штуки, которые необходимо запустить к конкретному сроку (или как рассчитать этот срок)?
Как я себе вижу: цели личные можно ставить тогда, когда человек за них может отвечать, то есть, хватает управленческого инструментария.
Можно ли поставить прорабу цель "сделать 100 квартир за год"? Наверное, можно, если он и клиентов ищет и поставляет. А если клиентов ему "приводят", а шпатлёвку выдают с задержкой в месяц?
Мне кажется, что тимлиду поставить личную цель "заработать Х денег" можно тогда, когда он вот прямо за весь цикл полностью отвечает — от приведения клиентов до проводки платежей. А иначе — поставил ты такую цель, а бухгалтерия или продажники мешают или не помогают, и что будет? Негативные социальные динамики начнут появляться — тимлид начнёт злиться, ругаться, те будут в ответ, в общем, вместо коллективной работы какая-то ерунда начнётся. Посмотри фильм Премия про это, прямо очень хорошо показывает ситуацию.
С запуском проекта уже, кажется, лучше ситуация. Но нужно ли именно к дате запускать проект? Почему нужно? Давай разбираться. У тебя контракт fix price?
Я к чему это всё — чем на более раннем этапе производства ПО уменьшить сложность, тем дешевле и легче трудиться.
Представь гипотетическую ситуацию — в описании задачи написано, что нужно реализовать определённый функционал, но программировать надо, "каждые 5 минут отвлекаясь на выпивание пивка".
Исполнительный менеджер обеспечит бесперебойную поставку пива, и будет контролировать, что каждый сотрудник понимает, насколько важно каждые пять минут попивать это пиво. Некоторые начнут манкировать этой обязанностью, и не отвлекаться.
Менеджер, видя это, придумает "систему мотивации", побуждающую к неукоснительному следованию правила "каждые 5 минут выпивать пивка". Начнёт, например, логгировать количество отвлечений сотрудника. Сотрудники поймут, что можно просто отвлекаться, не выпивая пиво, но лишь пригубливая. Менеджер начнёт придумывать другие варианты контроля.
Или, возможно, все сотрудники будут очень обязательными, и каждые 5 минут будут выпивать пивка, но менеджер заметит, что к обеду все уже будут основательно пьяными, и производительность падает. Менеджер может попробовать выделять один день в неделю, когда все с утра в говно, и типа "выполнили норматив недельный по отвлечениям", а остальные дни уже работают хорошо и спокойно. Или менеджер может выделить отдельного алкоголика, который только сидит и упивается, пока все остальные работают.
Но, как ты видишь, простое усложнение в начале цикла неизбежно обрастает всё большей сложностью на дальнейших этапах.
А что, если разобраться в ситуации? Откуда пошло требование "отвлекаться каждые 5 минут на выпивание пивка"? Вполне может оказаться, что у заказчика просто был такой опыт работы на хакатоне на Бали, когда все подбухивали и код писали.
Может, требование и не нужно окажется, и всю эту управленческую сложность можно убрать?
Но может быть и так, что, например, заказчик просто проводит бесчеловечный социальный эксперимент, и ценность для него именно в том, чтобы смотреть, как поведёт себя типовый разработчик в состоянии постоянного повышения состояния опьянения?
Тогда, может, и к проекту надо было подойти совсем иначе?
Я призываю разобраться в том, нужна ли эта сложность, убедиться, что если она и нужна, то нужна неизбежно. В типично продуктовой работе, например, чаще всего оказывается, что какие-то сроки и не нужны вовсе.
А в работе проектной, где контракты fix price, подход к прогнозированию и оценке совсем другой уже.
Ну и возвращаясь к твоему первоначальному вопросу "как бизнесу ставить цели тимлиду" — а давай попробуем разобраться, зачем бизнесу ставить тимлиду цели?
Какую пользу в добавлении управленческой сложности в виде постановки целей и контроля их исполнения ты видишь?
Для меня цель - это результат, который нужно достичь, с помощью цели у команды появляется понимание, чем нужно заниматься и в каком направлении двигаться
Не вижу смысла в контроле команды, но самой команде цель поможет не попасть в ситуацию разработки бесполезных штук, как например описывается в этой статье: https://medium.com/swlh/gold-plating-software-products-7bffe427b215
За фильм спасибо, посмотрю 👍