Thread by @vasilenkos

Сын уснул, так что самое время писать в твиттер.

Сегодня коснёмся проблем менеджмента в разработке ПО.

Самая, наверное, главная проблема любого менеджмента - сроки. Проблема менеджмента ПО в том, что сроки всегда будут сорваны.

Почему это происходит? Самый верхний ответ - из-за проблемы недооценки. И это полуправда, ведь недооценка лишь следствие других, более фундаментальных и менее очевидных моментов. Например, из-за того, что идёт неправильное разделение задач на масштабируемые и немасштабируемые.

или из-за того, что при раскладке задач не учитываются личностные особенности исполнителей. Также, зачастую, забывают о том, что в оценку задачи необходимо закладывать, кроме непосредственно грубых прикидок по исполнению и итеративному глянцу, ещё и этап проектирования.

Отдельные проблемы оценки - кумулятивные зависимости и дрейф требований. А самая глубинная проблема ошибочной оценки и, самая, на мой взгляд, важная, - это выбор стратегии оценки и соисполнителей в выполнении оценки.

Пробежимся сверху вниз. Итак, разделение задач на масштабируемые и немасштабируемые. У любого менеджера есть опыт, который так или иначе подсказывает ему, как отделить итеративно выполняемые задачи от нестандартных, уникальных. К сожалению, этот опыт зарабатывается кровью.

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

И, если есть минимальное подозрение по поводу того, что горизонтально масштабируемое, клонируемое решение может приобрести вариативность, закладывайте коэффициент 1.5 в оценку. Это спасёт вас от факапа на ВНЕЗАПНО вылезшей необходимости реализовать сценарность.

Ещё один подвид ошибок оценки масштабируемости - избыточное доверие обобщённым решениям в слоистых архитектурах без учёта вышележащих и нижележащих слоёв абстракции. Аналогично, если есть хотя бы минимальная вероятность разрастания межслоевого интерфейса - переоценивайте.

С истинно масштабируемыми потоковыми задачами тоже бывают проблемы оценки, но эти проблемы уже относятся к качеству управления непосредственными исполнителями. Если у вас есть такая задача, то не поленитесь и регламентируйте её выполнение так, чтобы бутстрапить под контролем.

Чем больше регламентной работы проделает менеджер и чем более чётким шагом будут ходить исполнители в таких задачах, тем точнее будет оценка и тем меньше будет оверхед на комбинаторике личсостава. Вроде очевидная вещь же!

Теперь про личностные особенности. Есть простые правила: чем больше мощность исполнителя как инструмента решения задачи и чем выше его автономность, тем больше надо закладывать коэффициент на проектирование задачи. Так вы застрахуете свои усилия по убеждению за линию партии.

Однако, чем меньше мощность исполнителя и чем выше инициативность, тем больше надо закладывать коэффициент на регрессиронные осаживания этого исполнителя.

На каждый уровень индирекции закладывайте коэффициент 1.5. Это избавит вас от проблем с неизбежными потерями в информационных потоках от вас до нижнего уровня.

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

Самый простой способ для этого - составьте кортеж важных для вас или для вашей оценки характеристик и нарисуйте по ним для каждого радиальную диаграмму с осями, соответствующими этим характеристикам. В качестве коэффициента для исполнителя закладывайте меру удаления её от круга.

Более сложный способ - взвешенный граф качеств. Но это всё уже вкусовщина. Главное - всегда понимайте, что за люди у вас работают. Категорически нельзя красить исполнителей одним цветом и относиться к ним одинаково в плане оценки.

Теперь про этап проектирования. Лично мой опыт говорит о том, что этап проектирования задачи отнимает столько же времени, сколько разработка решения. Но, при этом, суммарные затраты на этап проектирования и этап решения меньше, чем на решение без этапа проектирования.

Тут есть тоже несколько очень странных моментов. Момент первый: бейте этап проектирования на три подэтапа: грубо-сценарное, обще-компонентное и мелко-детальное. Момент второй: не нависайте. Дайте возможность исполнителю сделать минимум три итерации по каждому из подэтапов.

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

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

Теперь про дрейф требований и кумулятивные зависимости задач. Дрейф требований, если этап проектирования по задаче сделан правильно, принимает регрессионный характер (правится уже задокументированный эскизный проект).

Тут важно понимать две вещи: первое - если эскизное проектирование перешло в этап разработки решения и задача не имеет зависимостей, то регрессию надо будет выводить на уровень планирования выше и не останавливать текущие работы;

второе - если дрейф затрагивает задачу с зависимостями и разработка решения по ней ещё не начата, то все подзадачи надо принудительно отправлять на регресс эскизного проектирования.

и ещё. Если у вас есть граф кумулятивных зависимостей, то исполнителей на узловые задачи ставьте с шириной радиальной характеристической диаграммы соразмерной уровню узла. Чем выше уровень тем шире диаграмма.

Отдельная проблема с дрейфом требований - умение говорить "нет" менеджменту верхнего уровня и умение говорить "надо" исполнителям. Очень сложные в отработке умения, на которые уходит большая доля здоровья.

Теперь скушаем вишенку. Выбор стратегии оценки.

Оценку никогда нельзя делать авторитарно, равно как и нельзя её оставлять на откуп исполнителю. Первое - самодурство, замешанное на фальшивом опыте. Второе - безответственность.

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

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

Самый простой способ получить оценочные данные от дивизионов - сформулировать список контрактов для задачи и крупноблочно обрисовать их композицию, при этом специально внедрив в этот описательный материал ошибки и грубые лакуны. Заставьте задор оценщиков работать на вас :)

После того, получения корректив обрисуйте грубый эскизный проект в стиле описания поведения в системе трекинга задач и отдайте достаточно компетентному (желательно - целевому) исполнителю с просьбой прокомментировать узкие места корректив.

И вот после этого уже у вас будет начальный материал для расчёта коэффициента умножения линейных затрат сообразно сложности задачи и вы сможете с учётом этого коэффициента передать задачу на оценку целевому исполнителю. Причём оценивать надо вместе с ним, рядом.

Разбиение на подзадачи и эскалирование в данном случае примитивные по своей сложности и труда уже не представляют.

Остаётся умножить эстимейт на 2 и вы получите итоговый срок. Если проект хардварный, то сдвиньте ещё и единицу измерения. Час->сутки, сутки->неделя, неделя->месяц.