Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 45
Поясните пожалуйста форму для временной оценки
Это просто империческая формула, выведенная по статистке завершенных проетов. Если за ней и стоит како-то объективный закон, то мы его не знаем. Но наше незнание нас от него не освобождает
Что значит N в формуле?
трудоёмкость. ч.*м. citforum.ru/SE/project/arkhipenkov_lectures/7.shtml
наверное, имели в виду эмпирическая, основанная на опыте, а не на приказе (императив) :)
Неопределённость можно выражать и преподносить через оценку рисков. Эта часть темы не раскрыта совсем.
У автора топика совсем недавно была статья про риски. Похоже на то, что он скрыл её в черновики (потому что я свой коммент не могу найти даже в «моём»).
Насчет этого топика можно сказать, что не любая неопределенность — риск. Риск — это событие, а неопределенность — это неточность наших знаний о настоящем и будущем, результат того, что мы что-то недопонимаем/не знаем. Т.е. конус неопределенности оценок сроков завершения — это еще не риск, но уже неопределенность, и ее изучали отдельно. Риском будет «не успеть» к конкретной дате.
Насчет этого топика можно сказать, что не любая неопределенность — риск. Риск — это событие, а неопределенность — это неточность наших знаний о настоящем и будущем, результат того, что мы что-то недопонимаем/не знаем. Т.е. конус неопределенности оценок сроков завершения — это еще не риск, но уже неопределенность, и ее изучали отдельно. Риском будет «не успеть» к конкретной дате.
Ничего удивительного. Люди ведь не изменились с «далекого» 1975 года :)
Даю две подсказки:
1. Многие ли люди читают книги, если нужно найти ответ на вопрос/проблему?
2. Редко ли те, кто прочитал толковую книгу, говорят: «ну это только в книгах все так хорошо»?
Даю две подсказки:
1. Многие ли люди читают книги, если нужно найти ответ на вопрос/проблему?
2. Редко ли те, кто прочитал толковую книгу, говорят: «ну это только в книгах все так хорошо»?
А если бы сроки всегда можно было оценить, то Windows Vista вышла бы в 2005м, а не в 2007м и содержала бы в себе объектно-ориентированную файловую систему, про которую рассказывали красочные буклеты в 1993м.
Разработка ПО больше всего похожа на ремонт, который, как известно, невозможно закончить но можно только прекратить. То же самое и тут: выживают не фирмы, способные как-то прогнозировать сроки (таковых в природе нету), а фирмы способные убедить заказчика принять то, что в оговоренные сроки удалось сделать как «ну-почти-то-что-вы-в-общем-то-и-хотели».
Разработка ПО больше всего похожа на ремонт, который, как известно, невозможно закончить но можно только прекратить. То же самое и тут: выживают не фирмы, способные как-то прогнозировать сроки (таковых в природе нету), а фирмы способные убедить заказчика принять то, что в оговоренные сроки удалось сделать как «ну-почти-то-что-вы-в-общем-то-и-хотели».
Книжка, да, хороша. Но я не очень верю в то, что в вузах на ИТ специальностях у нас вот-так скоро начнут учить выстраивать процессы. Планирование — это ведь процесс. Вот в автошколах сначала учат правилам, а потом вождению. А программистов сначала учат быстро-быстро кодить, а потом… а ничего потом. Потом они попадают с реальные условия, совершенно не умея (чаще всего) по уму применять свои знания.
Я думаю, что опытные девелоперы лучше планируют, помому что принимают во внимание больше аспектов, связанных с задачей. Именно в мелочах часто кроется «неучтенное» время. Может быть главная польза от планирования — это сам факт поиска неочевидных штучек-дрючек в задаче.
Я думаю, что опытные девелоперы лучше планируют, помому что принимают во внимание больше аспектов, связанных с задачей. Именно в мелочах часто кроется «неучтенное» время. Может быть главная польза от планирования — это сам факт поиска неочевидных штучек-дрючек в задаче.
Сроки = себестоимость.
В первом приближении, да.
Если бы сроки невозможно было оценить, то фирмы, разрабатывающие ПО не существовали бы — они бы не могли бы выставлять счета клиентам.
Их было бы меньше, но они остались бы — просто выставлять счета по факту, оплачивая разработку из собственных или заемных средств. Или договариваясь с заказчиками на «почасовой рэйт» как, по сути, при внутренней разработке.
очевидно вы не имели заказчиков со всяких телекомов газ и прочих промов
Если в двух словах: для fixed bid проектов с большой долей неизвестности почти гарантировано будет даваться близкая к верхней оценке величина. Даже для dedicated team в вопросах строков хотят comitment что заявленные сроки будут исполнены.
Как окологосударственные и не только компании ищут себе подрядчиков? Создают тендер. А дальше риски оказываются в цене.
Добавим очень частую ситуацию, когда детали вы утверждаете с профессионалом представителем заказчика, но он не является decision maker, а decision maker человек далёкий и специалист с совсем другими навыками или вообще без оных.
Как окологосударственные и не только компании ищут себе подрядчиков? Создают тендер. А дальше риски оказываются в цене.
Добавим очень частую ситуацию, когда детали вы утверждаете с профессионалом представителем заказчика, но он не является decision maker, а decision maker человек далёкий и специалист с совсем другими навыками или вообще без оных.
Перед каждым участником разработки встаёт этот вопрос, и не раз. Каждый раз, переходя на новую ступень или на новую должность, смотришь на проблему по-новому. Я, например, основные причины неадекватности оценок (и возможные способы повышения их адекватности) сформулировал для себя так: greesha.livejournal.com/11358.html
А я не такой плохой оценщик, только с городами, в которых есть метро сильно ошибся
Точка зрения из экосистемы аутсорс/интеграции:
На эту тему есть несколько точек зрения:
1. Разработчик, которому необходимо обезопасить себя и менеджера от факапа по срокам
2. Менеджер, которому необходимо обезопасить себя и команду от факапа и продать максимально дорого в реальных условиях
3. Руководитель менеджера, которому нужно выполнить план по обороту любой ценой
4. Заказчик, которому нужно как можно дешевле при гарантированном качестве и у которого есть еще несколько предложений.
В ваккуме все это порождает порочный круг «эффективного менеджмента», «урезания костов» и прочих вещей, ведущих к плохому коду и недовольству всех участников этого шоу.
2 случая из практики:
1. крупная система, договор по сдельной оплате, каждая задача проходит 3х ступенчатую проверку трудоемкости и согласование техкомитетом (с представителями бизнеса). Архитектору приносят ТЗ на изменение куска ядра, по которому нет документации. Он, не будь дурак, вычленяет все отдельные блоки ТЗ (60 штук) и на каждый дает 3 дня. По итогу задача утверждается на ТК с трудоемкостью около 70 дней и делается за 120. Все недовольны, штрафы субподрядчику, задачу просохатили на календарный месяц по срокам сдачи.
2. Другая крупная система, договор по абонентской плате. Разработчикам дана строгая установка в оценках быть пессемистичными, согласование трудоемкости с заказчиком идет на предмет адекватности (не может отчет из 2 форм дорабатываться 60 дней, верно? :)), с бизнесом согласовываются сроки деплоя задачи на бой (сроки даются после планирования), исключение — задачи, связанные с законодательством. Процент попадания в сроки — ~95%, все довольны.
Считаю, опасно рассматривать эту проблему только с точки зрения разработчика.
На эту тему есть несколько точек зрения:
1. Разработчик, которому необходимо обезопасить себя и менеджера от факапа по срокам
2. Менеджер, которому необходимо обезопасить себя и команду от факапа и продать максимально дорого в реальных условиях
3. Руководитель менеджера, которому нужно выполнить план по обороту любой ценой
4. Заказчик, которому нужно как можно дешевле при гарантированном качестве и у которого есть еще несколько предложений.
В ваккуме все это порождает порочный круг «эффективного менеджмента», «урезания костов» и прочих вещей, ведущих к плохому коду и недовольству всех участников этого шоу.
2 случая из практики:
1. крупная система, договор по сдельной оплате, каждая задача проходит 3х ступенчатую проверку трудоемкости и согласование техкомитетом (с представителями бизнеса). Архитектору приносят ТЗ на изменение куска ядра, по которому нет документации. Он, не будь дурак, вычленяет все отдельные блоки ТЗ (60 штук) и на каждый дает 3 дня. По итогу задача утверждается на ТК с трудоемкостью около 70 дней и делается за 120. Все недовольны, штрафы субподрядчику, задачу просохатили на календарный месяц по срокам сдачи.
2. Другая крупная система, договор по абонентской плате. Разработчикам дана строгая установка в оценках быть пессемистичными, согласование трудоемкости с заказчиком идет на предмет адекватности (не может отчет из 2 форм дорабатываться 60 дней, верно? :)), с бизнесом согласовываются сроки деплоя задачи на бой (сроки даются после планирования), исключение — задачи, связанные с законодательством. Процент попадания в сроки — ~95%, все довольны.
Считаю, опасно рассматривать эту проблему только с точки зрения разработчика.
Очень помогает оценка по «женскому» времени: берем первоначальную оценку времени и умножаем на число пи.
Боюсь, что бизнесу на этот пост, мягко говоря, плевать. По крайней мере — большинству средних предпринимателей, не понимающих, насколько на самом деле важна «прослойка между стулом и монитором», работающих не на эффективность в целом, а на результат прямо сейчас.
В какой-то книжке читал про формулу оценки времени, необходимой для разработки — возмите время, сказанной программистом, умножьте на 2 и переведите в следующую единиицу времени.
В справочнике Стеля таких формул с избытком.
Видимо Вы являетесь ПМ'ом?
ПМ по умолчанию — корень всех бед?
Нет, я админ, вернее — технический консультант, так написано в трудовом договоре.
И ко мне часто ПМы приходят с вопросом — сколько может занять времени та или иная задача. И я обычно даю всегда два ответа — если все пойдет хорошо, то это одно время (оптимистичный прогноз), а если на каком-то этапе возникнут проблемы, то необходимо увеличивать этот прогноз на время решения проблем, естественно, не всегда можно точно сказать, сколько именно времени необходимо на решение проблем на каждом этапе. При этом я стараюсь донести до ПМ все возможные проблемы на каждом этапе, как их можно будет порешать и сколько ориентировочно это может занять времени — обозначить риски, так сказать.
Не хочу так же сказать, что я пользуюсь тем правилом, которое озвучил, скорее наоборот — обычно мои прогнозы по оценке затрат времени на мою работу имеют погрешность не более 15-20%.
А та формула, которую я привел, это, на мой взгляд, разное видение задачи с точки зрения программиста и ПМ. Программист смотрит на задачу — реализовать такую-то фичу, — думает про себя, — ну эт несложно, вот тут добавим и все — дел на час. И озвучивает час. А ПМ нужна эта фича уже в готовом продукте, соответственно, помимо программиста, написавшего эту фичу, необходимо прогнать ее через отдел тестирования, проверить, нет ли багов, исправить их, если вдруг они появились и только после этого только получить продукт с такой фичей. И тогда действительно, час вполне может превратиться в 2 дня.
И ко мне часто ПМы приходят с вопросом — сколько может занять времени та или иная задача. И я обычно даю всегда два ответа — если все пойдет хорошо, то это одно время (оптимистичный прогноз), а если на каком-то этапе возникнут проблемы, то необходимо увеличивать этот прогноз на время решения проблем, естественно, не всегда можно точно сказать, сколько именно времени необходимо на решение проблем на каждом этапе. При этом я стараюсь донести до ПМ все возможные проблемы на каждом этапе, как их можно будет порешать и сколько ориентировочно это может занять времени — обозначить риски, так сказать.
Не хочу так же сказать, что я пользуюсь тем правилом, которое озвучил, скорее наоборот — обычно мои прогнозы по оценке затрат времени на мою работу имеют погрешность не более 15-20%.
А та формула, которую я привел, это, на мой взгляд, разное видение задачи с точки зрения программиста и ПМ. Программист смотрит на задачу — реализовать такую-то фичу, — думает про себя, — ну эт несложно, вот тут добавим и все — дел на час. И озвучивает час. А ПМ нужна эта фича уже в готовом продукте, соответственно, помимо программиста, написавшего эту фичу, необходимо прогнать ее через отдел тестирования, проверить, нет ли багов, исправить их, если вдруг они появились и только после этого только получить продукт с такой фичей. И тогда действительно, час вполне может превратиться в 2 дня.
Это из тех книжек где пишут про необходимость создания конкурентной атмосферы в коллективе, порядок расстановки кактусов перед монитором под обложкой «12,5 шагов к эффективному менеджменту»?
Хороший ПМ зачастую выходит из исполнителей (QA/Dev/Analytics), неплохо разбирается в подотчетной системе и в состоянии адекватно оценить оценку разработчика
Хороший ПМ зачастую выходит из исполнителей (QA/Dev/Analytics), неплохо разбирается в подотчетной системе и в состоянии адекватно оценить оценку разработчика
Как то странно вы сделали, мягко говоря… «Приведите оценки от… и до… для следующих величин:» — для физических величин и фактов, которые нагуглить совсем не трудно. В реальности же требуется «угадывать» не величины, а временные интервалы, причем на основании аналитики и опыта. Какой опыт может помочь в определении длины реки? Ну на бред же прхоже. Попытка смешать в кучу не смешиваемое.
… требуется «угадывать» не величины, а временные интервалы...
Не понял. Временные интервалы чего?
По сути. Кейз приводился на семинаре (естественно без всяких гуглов) для того, чтобы люди ощутили, что такое неопределенность. В каких-то вопросах она меньше. Например, человек Химик. В каких-то больше, например, не учил в школе географию и не знает где течет Днепр.
Как-то так.
Задача как поставлена: на глазок прикинуть параметры, которые нет реальной необходимости прикидывать — их можно относительно легко узнать. Зачем прикидывать то, что можно узнать? Там нет неопределённости, там есть вещи, которые люди не знают, но могут легко узнать, не тратя много времени. Пример высосан из пальца.
В реальном проекте часть вещей нельзя узнать, пока ты их не сделаешь, например, производительность разработчика, который пришел к вам фирму два дня назад. Вот это — неопределённость.
В реальном проекте часть вещей нельзя узнать, пока ты их не сделаешь, например, производительность разработчика, который пришел к вам фирму два дня назад. Вот это — неопределённость.
При таких вопросах может возникнуть ложное ощущение «меня спрашивают то, что я не знаю, но могу легко узнать» => «срок разработки тоже легко узнать».
По собственному опыту могу сказать, что в плане оценок сроков выполнения задач действует правило 90/10.
90% задач очень хорошо поддаются оценке. Как правило, это типовые задачи.
10% дают очень большое непопадание в первоначальных оценках.
Это я привожу цифры в отношении тех задач, выполнение которых зависит только от меня.
В интеграционных задачах, в задачах, где нужно использовать open-source либы, не проверенные временем правило 90/10 уже не действует.
90% задач очень хорошо поддаются оценке. Как правило, это типовые задачи.
10% дают очень большое непопадание в первоначальных оценках.
Это я привожу цифры в отношении тех задач, выполнение которых зависит только от меня.
В интеграционных задачах, в задачах, где нужно использовать open-source либы, не проверенные временем правило 90/10 уже не действует.
Прикольно — сроки виртуальные, а оплата фиксированная. Если человек — профессионал своего направления, делает на заказ работу, в которой он имеет большой опыт, разве не может он дать реальную оценку готовности продукта? Я понимаю, когда надо делать что-то совершенно новое, когда нет опыта решения конкретных задач и понимания подводных камней. Но большинство программистов, что мне довелось видеть как правило специализируется на конкретных видах заказов и типовых проектах.
Насчёт типовых заказов — оценить приблизительно, что почём, конечно, можно.
А если речь идёт о большом проектах, а задачи могут меняться в зависимости от сложности конкретного заказа и, да-да, сложности конкретного клиента?
Даже документированные требования к проекту — это по факту филькина грамота, устаревающая, как только доходит до дела (насколько я имею об этом представление, переданное от признанных авторов типа Стива Макконелла). На практике, скорее всего, всё жёстко. Только если сама команда — не слаженно и работающий монолитный механизм: тогда, конечно, будет легче и оценивать сроки, и задачу выполнять.
А если речь идёт о большом проектах, а задачи могут меняться в зависимости от сложности конкретного заказа и, да-да, сложности конкретного клиента?
Даже документированные требования к проекту — это по факту филькина грамота, устаревающая, как только доходит до дела (насколько я имею об этом представление, переданное от признанных авторов типа Стива Макконелла). На практике, скорее всего, всё жёстко. Только если сама команда — не слаженно и работающий монолитный механизм: тогда, конечно, будет легче и оценивать сроки, и задачу выполнять.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Объясняем бизнесу, почему у нас такие «фиговые» оценки