Comments 21
А что делать, если в процессе следования по дорожной карте оказывается, что маршрут был проложен неверно (либо команда свернула по нему "не совсем туда"? Т.е. оценка резко увеличивается из-за какой-то ошибки.
По туристской аналогии: при передвижении по сильно пересечённой (горной) местности велика вероятность ошибки. И вы можете в итоге стоять от цели в 10 метрах геометрически, но что бы туда попасть, надо идти ещё пару суток. А всё из-за того, что случайно (в тумане и т.д.) свернули раньше/позже срока.
А если этой ситуации не избежать, то нужна ли вторая оценка (по разбиению работы на этапы) и нужно ли на неё тратить отдельное время? Мы же первоначальную оценку делаем для того что бы понять "съедим ли мы слона хотя бы теоретически". Может, оценку по более мелким этапам работ делать в момент, когда хотя бы по вводным для них всё понятно?
Вы подсветили хороший сценарий.
Действительно, в проектах оценка может проводиться в несколько этапов:
- есть первоначальная оценка, когда заказчик хочет просто узнать сколько будет стоить. В этом случае, вкладываться в детальную оценку и составлять подробную дорожную карту нет смысла. Заказчик просто приценивается, поэтому и количество трудозатрат должно быть соответствующим.
- есть оценка фичи, когда уже есть заказ от заказчика, есть требования и нужно сделать оценку, чтобы сообщить заказчику, когда ориентировочно получит свою фичу. Здесь можно оценку сделать уже более детальную, чем в первый раз.
- есть оценка конкретной задачи, когда уже фича в работе. Вот здесь как раз и нужно прям детально фиксировать и разбивать задачу на подзадачи, которые представляют собой маршрут её решения.
Поэтому считаю, что трудозатраты по оценке должны быть соразмерными с этапом проекта. Другими словами, детализация дорожной карты зависит от того насколько близко она к началу реальных работ.
Таки правило «умножить первичную оценку на пи и на e» нашло подтверждение в графиках и собранной статистике 😅?
К сожалению, не понял вашего вопроса. Поясните, пожалуйста.
Ну в айтишных кругах ходит прикол - чтобы получить реальное время выполнения задачи, надо первичную оценку, данную условным программистом, умножить на число пи (~3.14) и число е (~2.7). Так как оба числа являются иррациональными (так же как порой и сами задачи в стиле "Реализовать статусную модель") и отражают фундаментальные математические вещи, что позволяет увязать это с математикой и получить реальное число в часах/днях/месяцах.
Согласен с фокусом на дорожную карту. В 2014 году жизнь заставила подрядиться и за месяц налепил графику по писанному профи декомпозиции, где срок фактической и окончательной реализации проекта совпал с предполагаемым месяц-в-месяц.
ЗЫ: прикол в том, что реально всё заказчики и субподрядчики аффигели от этого роудмэпа, по жизни привыкшие работать строго по Гранту, по которому сроки окончания всегда сдвигались намного вправо)
Экспертная оценка по этой задаче составила: 24ч.
Увы, единственный приведённый в статье пример никак не подходит к её теме: оценка крупных задач. Соответственно, оценить достоверность методики на таком примере невозможно.
С статистической точки зрения, вы абсолютно правы. Поэтому математически, демонстрация всего одного примера не может служить прочным доказательством того, что на множестве других задач он будет выполняться тоже.
С другой стороны, я не могу приложить в статью все примеры из своей практики. Статья и так получилась объёмная. И новые примеры раздули бы её ещё больше. Скажу только то, что за 4 года использования этой методикой оценки - она давала очень хороший результат. И за это время я сдал все свои проекты в срок.
Цель моей статьи: донести идею и свой опыт решения проблемы с точной оценкой задач. А применять ли эту методику на практике или нет - решать уже вам.
я не могу приложить в статью все примеры из своей практики
Все и не нужны. Но 24 и даже 88 часов – это мелкая задача, в тему статьи никак не попадает. Единственное, что можно понять из этого примера – уровень экспертизы тех, кто оценивал трудоёмкость явно невысок, ошибка в 4 раза для эксперта недопустима.
Что же касается самой методики, то на мой взгляд, она может быть пригодна для оценки стандартных задач, с которыми всё понятно, и по сути точность оценки есть производная качества декомпозиции. Для незнакомых и/или расплывчато сформулированных (что встречается сплошь и рядом) – не уверен.
Если задача оценивается в 80+ часов с ней уже что-то не так и её необходимо декомпозировать, так что методология из статьи подходит для примера. Если задача оценивается в 200-500+ часов на одного человека, это не задача, а мазок из бизнес-требований, который требует проработки и декомпозиции прежде чем он станет набором задач. Опять таки, требование -> набор задач, методология из статьи подходит, хоть некоторые скорее всего могут разрабатываться параллельно, это все равно своеобразный roadmap.
Единственный пример, когда задача может быть оценена в 500 чч, который я могу придумать - это задачи в гигантах индустрии, где 500 человек потратят каждый по одному часу, чтобы внедрить изменения, но подобные задачи находятся за скоупом обсуждения в этой статье, на мой взгляд, т.к. фактически исполнителю попадает задача с оценкой в 1 час.
На моей практике задачи в 40 часов это хард лимит, на который я готов согласиться без декомпозиции. Иначе задача так и будет висеть из недели в неделю с невнятным статусом, и окажется, что оценка была произведена неверно.
С незнакомыми задачами соглашусь, но как оценивать незнакомые - за рамками обсуждения. Про расплывчатые требования - это и есть задача тимлида/менеджера/системного аналитика, в зависимости от процессов, уточнить требования для разработчика.
На моей практике задачи в 40 часов это хард лимит, на который я готов согласиться без декомпозиции
Возможно, тут имеет место несовпадение терминологии. С моей т.з. крупная задача – это нечто комплексное, выходящее за рамки одиночного тикета. Которые, в свою очередь, уже являются результатом декомпозиции и в норме действительно требуют максимум человеко-неделю. Исключения встречаются, но их следует избегать.
Безумно много воды и бессмысленных аналогий
У меня такое ощущение, что всем айтишникам надо поработать в промышленности. Такую смешную ахинею пишут про нормирование трудоемкости. Желательно бы еще всем айтишникам окончить ВУЗ, простой машиностроительный или строительный (лучше да, строительный) ВУЗ.
В промышленности "оценка" называется "Нормирование трудоемкости".
Нормирование (это в принцице) возможно только:
Для одинаковых операций. Точнее, для тех, которые в принципе известны.
Для тех операций, которые когда-либо делались.
Только для того изделия, которое имеет проект. Имеются чертежи со всеми составляющими. Вплоть до последней детали.
Имеются набор продуманных операций для каждой детали.
Все операции известны, когда-либо делались, записывалась трудоемкость этой операции. А также сложность, размеры, вес детали и так далее, все факторы, влияющие на трудоемкость. Пример - длина сварного шва, размер катета.
Чтобы нормально просчитать трудоемкость, нужно следующее.
Нужен детальный проект. Не "мечта" менеджера, бгг. "Мечта менеджера" в промышленности - это техническое задание на самом-самом начале, текстовка с описанием. Должен быть проект, "чертежи". По которым исполнитель может наваять программу. Вообще любой исполнитель-программист, знающий язык программирования и нужные технологии. Знание бухгалтерии или еще каких предметных областей - совершенно будет не нужно, что требуется сейчас от экспертов-сеньеоров. Кстати, и для контроля такой проект нужен - чтобы по проекту любая девочка-контролер могла протестировать.
Затем нужен отдел нормировщиков - специально обученные люди, которые по проекту, имея справочники, свои тетради и прочие материалы, зная, какие "детали" проекта и какой они сложности, могут по своим таблицам определить, сколько будет трудоемкость изготовления данного компонента/детали. Это "НЕ НОРМА!", когда менеджер или исполнитель, определяет, какая трудоемкость определенного компонента.
В ИТ, в отличии от двухсотлетней системы в промышленности, действует модель стартапа (гаража, узбекской бригады плиточников).
Заказчик хочет сделать продукт. Он имеет "мечту".
Сколачивает брагада стартапа из десятка
узбековпрограммистов. Они читают хотелки и прикидывают, сколько у них займет времени каждый элемент работы.Озвучивают заказчику.
Заказчик чешет репу, и либо, соглашается, либо бежит дальше по рынку.
Бригада начинает ишачить.
Если ребята выполняют работу в срок - им оплачивают работу, они ищут нового
лохазаказчика.Если не успевают - либо увеличивают сроки, без увеличения оплаты и работают себе в минус. Либо выциганивают увеличение сроков и бюджета. Можно повторить. Проваливают проект, стартап банкротится, разрабы разбегаются. Заказчик терпит убытки.
Перейти к п.1.
Вся нынешняя система "определения трудоемкости" - гадание на кофейной гуще, ваша "система" - тоже самое, и предполагает либо угадывание и получение прибыли, либо неугадывание и банкротство вашей шараги с последующим выкупом команды в следующую шарагу.
Сколько я таких "систем" видел - все чепуха, потому что никто не понимал необходимых условий, которые я привел вверху. Все - разные системы гадания.
Отличие вашего примера в том, что бригада индусов плиточников вам не сможет случайно сделать ремонт-еднорог, который принесёт заказчику 100х (даже более?) к вложению. А бригада стартаперов - может.
Не все мечты одинаково масштабны )
@DenSigma Очень хорошее описание. Именно такой лаконичный и зрелый текст рассчитывал встретить в тексте на тему этой статьи.
Спасибо за ваш развёрнутый комментарий. С интересом почитал.
Могу только его дополнить тем, что модель работы, которую вы описываете в промышленности в ИТ называется Водопад. Она широко была популярна где-то до начала 2000-х годов. И сейчас считается неэффективной, т.к. в ИТ сейчас чертежи деталей могут меняться каждый месяц, оборудование на котором вытачиваются детали (пишут код) тоже постоянно меняется и оборудование очень сложное, в котором сотни тысяч, а в некоторых и миллионы маленьких деталей разработанных огромным количеством, зачастую, никак не связанных друг с другом людей.
Другими словами, сейчас на производстве в ИТ нет ничего фиксированного, всё может поменяться буквально через месяц-два, а бывает и чаще. И в такой среде традиционные способы оказываются мало эффективны, т.к. они рассчитаны на статическую среду, когда изменения происходят неспешно и измеряются годами, а не месяцами или неделями, как это сейчас происходит в ИТ.
К сожалению много воды про формулировки задач, мечты и прочее. Так и не дочитал.
Есть определение для крупного проекта Например проект в 4000 трулочасов является крупным?
Есть категоризация проектов под типовые и не типовые? С типовыми мне все предельно ясно и методы оценки не нужны. С нетиповыми - разложить по типовым, посмотреть на риски и посчитать. В чем сложность?
Судя по вашим формулировкам и вопросам, вы привыкли оперировать категориями. Мышление категориями - это полезный инструмент, сам им пользуюсь довольно часто, но к сожалению, у него есть недостаток: категории - это очень относительное понятие. И чертить границы категорий можно как угодно в зависимости от ситуации и задачи. Поясню на примере:
Представьте себе руководителя проекта (РП). Он привык работать с проектами, срок которых от полугода до 2-х лет. Исходя из его опыта, у такого человека вычерчивается допустим следующие категории размеров проектов: маленький (6 - месяцев), средний (12 месяцев), крупный (24 месяца). Теперь представьте себе руководителя разработки. Он привык работать не с проектами, а фичами. Сделать фичу в продукте - это проект для руководителя разработки. Исходя из его опыта, у такого человека категории размеров его проектов (сделать фичу) отличаются от аналогичных категорий РП. Для него маленький проект - 1 месяц, средний - 3 месяца, крупный - 6 месяцев.
Поэтому ваш первый вопрос не понятен, если вы не указываете объект с позиции которого будет даваться определение.
По второму вопросу, если кратко, то сложность в том, что типизация - не работает. Каждая задача уникальна и со своим контекстом. Да, можно группировать проекты в условно "типовые", чтобы например, определить стек технологий. Но из своего опыта скажу, что даже типовые задачи делаются по-разному. Например, типовая задача мониторинга в одном проекте, может быть реализована, совершенно по-другому в другом проекте. Другая реализация -> следовательно, другие трудозатраты и оценка.
Оцени меня, если сможешь. Методика точной оценки крупных задач