Тихон Козырев
По-моему, либо доверять инженерам и пусть они работу работают, либо уволить тех, кому не доверяешь и нанять тех, кому будешь доверять :)
Если под эффективностью понимать "прибыль"/"затраты" то непонятно как и в каких единицах их по отдельности-то мерить...
Человеко-время для проектной деятельности ещё Брукс развенчал. И как опыт показывает, такая единица измерения не показывает ничего - идентичную задачу два разработчика на одном и том же языке программирования решают один за три недели, а другой за день. Разный опыт, разные идеи.
KPI она в очередной раз проклянёт и унизит :)
Я бы, наверное, добавил ещё один шаг на 0.5 - "освободить систему" или "перестать на неё воздействовать", чтобы она пришла в своё естественное состояние.
Я лично вижу, что в разработке ПО зачастую есть какие-то метрики, от которых зависит финансовое вознаграждение исполнителей (типа количество фич, "скорость разработки", количество багов на тысячу строк кода и в таком духе) и эти метрики в лучшем случае смазывают картину реальной работы системы до неузнаваемости, а в худшем - полностью формируют её.
Тот же Голдратт писал, что одна из проблем на заводе была с простоем рабочих, потому что в головах рабочих "простой - это минус от зарплаты". Ему повезло - на заводе незаверншёнку можно увидеть в материальном воплощении и через это увидеть ограничение. А как такое провернуть в софтдеве - не понимаю.
Двоякое отношение к этой истории. С одной стороны: плохо, что не применили регламент там, где он нужен; с другой - хорошо, что не стали решать проблему с помощью неподходящих инструментами :)
Регламенты, как вообще любой инструмент, имеет ограниченную область применения. И по cynefin он соответствует простым (очевидным) средам. Мне видится, что принятие клиентской заявки попадает в область простых сред, значит регламент там имеет все шансы на успех. Он позволит: снизить требования к кандидатам при найме; сократить время обучения новых работников; обеспечить контроль; дать инструменты для стимуляции и всё в таком духе. Это же хорошо?
Регламент не решает проблему несоответствия ожиданиям клиента, но ряд проблем управления устоявшимся процессом - вполне.
Финансовую часть я обозначил весьма условно, потому что не могу себе позволить погружаться в нюансы какой-нибудь там юнит-экономики (мои познания в ней не позволяют это сделать). У моего комментария было два посыла: в первую очередь надо считать деньги; поздний выход продукта - может быть оправдан.
А то совершив предельный переход, можно дойти до того, что если стартап не принёс денег мгновенно, то никогда и не принесёт ;)
А так, да, нищий стартап (коих большинство) скорее всего не проживёт и года без продаж. Телеграм (по слухам) чуть меньше двух лет разрабатывался до выхода на рынок. Тоже стартап.
С Вами приятно общаться и мне нравятся ваши посты - с очень многим в них согласен :)
И в итоге "нафига я буду тут упарываться, если всё равно или продажники лажанут или саппорт обосрётся и премии за хорошую работу не видать?" :)
Для каждой степени "сырости" продукта считаем себестоимость продукта (суммируем затраты на разработку и произведения стоимости рисков на их вероятности) и ожидаемую прибыль (произведение ожидаемого количества клиентов на ожидаемую сумму с клиента).
Сразу выкидываем те, где идёт превышение доступного бюджета (собственные средства + кредиты + инвестиции и т. д.)
Из оставшихся степеней "сырости" выбираем ту, где будет разница между прибылью и себестоимостью будет максимальна.
Для ноунейм стартапа с его поделкой, полуторами разработчиков и бюджетом сопоставимым со средним чеком в макдоналдсе - как правило будет лучше выйти на рынок как можно раньше с весьма сырым продуктом. Для гигантов индустрии и продуктов с мировым именем - выпустить хотя бы medium rare.
По-моему, так :)
А можно поподробнее про то, как WIP связан с приоритетами?
Признаюсь честно и сразу: я так и не смог понять ТОС для проектной среды, поэтому в моей голове WIP - это инструмент из канбан-мира, где (как я понял) планирование редуцировано до ничтожности (просто фиксация на доске последовательности стадий выполнения задачи). А приоритизация - это непрерывный груминг и сортировка бэклога, а также выкидывание с доски задач, потерявших актуальность или ценность.
С точки зрения производства ТОС WIP нужны чтобы:
1. Визуально обозначить самый медленный узел цепочки ("барабан", если я правильно помню Голдратта)
2. Ограничить "связанный капитал" ("незавершёнку").
3. Обеспечить буфер для "барабана".
И у меня это всё никак не вяжется с системой приоритетов. Потому и спрашиваю :)
Окей. Тогда как насчёт такого варианта: "Борис ты хочешь, чтобы я сейчас делал задачу Б, но сейчас выполняю задачу A, которую мне поставил Артём. Если Артём мне скажет, чтобы я её отложил и делал задачу Б - то я так и сделаю, в противном случае задача Б будет поставлена в план работ на третий квартал 2027 года."?
Я понимаю, как исполнитель может определять последовательность выполнения для взаимозависимых задач (ну не получится застелить крышу шифером, пока нет обрешётки, а обрешётку никак не положить, пока стропила не установлены и т. д.). Но как он может решить, сейчас надо нарисовать логотип с пьяным кроликом для ООО "Вектор" или плакат с синим пришельцем для АО "Крыса и Ко"?
Не-не-не, я категорически не согласен с формулировкой "передать головную боль". Просто головная боль у всех разная: у исполнителя - выполнять задачи, у его начальника - руководить им (а это может включать и планирование работы исполнителя), у ПМ (по сути) риск менеджмент и ресурсное обеспечение проекта, которое в условиях дефицита - есть ни что иное, как грызня за ресурсы (в том числе и за время работы исполнителя).
Так что это скорее "не брать на себя чужую головную боль", чем не "передать головную боль кому-то".
Я бы сказал так, что система приоритетов работает "на отлично", когда задачи прилетают с указанием их приоритетов (числом, цветом или комментарием какие из текущих задач можно отложить на потом), а когда не прилетают задачи, когда уже все занято - это "на отлично" работает система планирования. И если она работает идеально, то и приоритезация свою актуальность теряет за ненадобностью...
Получается, что система приоритизация нужна для того, чтобы прикрывать провалы системы планирования. Спасибо за интересную мысль :)
Проблему переключений не решит, но позволит ограничить WIP. Плюс к этому это снимает вопросы от постановщиков задач "почему моя задача не двигается" и им подобные - в трекере задач сразу становится видно, какие задачи вытеснили её "в отдалённое светлое будущее". А психологически самое важное тут, что не исполнитель определяет "что важнее", а те, кто более компетентен в вопросах приоритезации.
Если у меня уже всё занято задачами, но прилетает новая важная и срочная от начальника я спрашиваю, на какую из текущих мне отложить. Пусть приоретизирует и сам решает, что важнее сделать.
Если же прилетает что-то новое от ПМ, то смотрю ПМов, для которых делаю текущие задачи и отсылаю его к ним - пусть между собой решают.
Так не проще?
А они в любом случае не будут работать по 8 часов, потому что это физиологически невозможно. Разница только в том, узнает об этом хозяин или нет :)