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