Комментарии 22
При этом, в повседневной жизни люди прекрасно справляются с планированием. Например, не опаздывают на самолет.
У меня ни разу не было такого, чтобы я планировал успеть на самолет к 15 часам, и был готов к тому что возникнет пробка, однако оказалось что пробка на конкретном участке МКАД устаревшей версии, если её апдейтить то аэропорт пропадает полностью и вместо него пустое поле, а если не апдейтить то при стоянии в пробке больше часа вылетает таймаут....
Я удивляюсь, как можно писать о планировании работ, и вообще не упомянуть диаграмму Ганта? То есть, вы планируете, планируете - и даже не представляете, какие у вас зависимости между задачами? И даже не пытаетесь визуализировать, где у вас критический путь? И применить готовый софт типа MS Project, который вполне может учитывать многие упомянутые параметры.
Определить зависимости между стадиями, спланировать параллельную работу с учетом этих зависимостей.
Ну т.е. вот же, прямо оно. Неужели сейчас этому вообще не учат (меня этому учили в институте, причем я учился на инженера)?
разработчик не знает, что такое Гантт, например. У него все зависимости в трекере проставлены)
а статья вполне работает для всех, кто дает сроки
Давайте чуть шире посмотрим на ситуацию. Я думаю, что у среднего разработчика нет навыков планирования. С этой проблемой я сталкиваюсь постоянно. И я хотел сформулировать некоторый минимальный, но достаточный набор приемов, которые можно брать и использовать.
Диаграмма Ганта, книги Голдратта и т.д. - это важно, но я хотел рассказать наиболее просто. И чтобы применить можно было даже к небольшой задаче. Ведь там тоже часто бывают промашки по срокам. Я не думаю, что софт типа MS Project стоит использовать, когда разработчику надо назвать срок готовности фичи, состоящей из трех-пяти задач.
Да, какие-то моменты в статье были под чуть больший масштаб, на вырост. Но я думаю это неплохо, когда логика планирования прозрачна для всех участников команды.
Если же планирование является основной работой, как, допустим, у проджект-менеджера, то врядли ему поможет статья типа этой
Ну давайте я чуть иначе выскажусь - на мой взгляд диаграмма Ганта это просто. И MS Project тоже. До определенного предела конечно - когда вы не занимаетесь рисками, т.е. не считаете вероятности, например. То что вы хотели еще дальше упростить - это все норм.
И когда у вас пять задач - то вероятно вам и критический путь очевиден без диаграммы. Но само понятие критического пути - это ведь тоже просто. Ну т.е. раз уж вы упомянули, что нужно определить зависимости, почему не визуализировать их в виде Ганта?
В общем, мой вопрос - он скорее из области образования. Почему в мое время простых инженеров учили планировать на коленке и рисовать Ганта (MS Project еще не существовал как класс), а нынешних простых разработчиков не учат? Может потому и навыков планирования нет, что не учат базе?
Спасибо, что пояснили. Я добавил в статью простые диграммы Ганта для наглядности. Думаю, стало лучше.
По образованию - не уверен, думаю дело обстоит сложнее. Ну во-первых, много ли в IT людей с техническим образованием? Не думаю, что больше половины. Я сам, например, без технического образования.
Во-вторых, во время учебы что-то могло отложиться в памяти, а могло и не отложиться. Это то же самое, что сказать - в школе все учили химию, значит должны уметь делать расчет количества вещества. Или была же начерталка, иди нарисуй деталь.
хорошая статья, че минусуют? Все по делу. немного много букв, но кто сможет дочитает и сделает хотя бы половину из написанного, получит профит :)
про самолет образ понравился. Главное в неопаздывании на самолет - это как часто вы им летаете. Было время, я все время летал. У меня была сумка, которую я мог собрать за 10 минут - и я на пути в аэропорт. Аэроэкспресс по расписанию, контроль - точно к посадке, чтобы было не надо ждать и захожу последним, чтобы не топтаться в рукаве.
Все было рассчитано точно, до копеечки. И достигнуто было, увы не теорией, а только практикой. Вот и учи разработчиков и менеджеров не опаздывать теперь. Учу учу, а все равно продалбывают :)
Пример с не опаздывают на самолет мне кажется немного скрывающий или упрощающий поднимаемую в статье проблему. Сама по себе эта задача уже является решенной и в ней все шаги (дорога в аэропорт, очередь на вход в аэропорт, паспортный контроль) известны и всего лишь нужно оценить понятные риски каждого шага, заложить буферы.
В разработке же мы довольно часто встречаемся с задачами, где порой не очень понятно под какие риски закладывать буферы и вообще какие риски сыграют роль в процессе реализации. При этом оценка первоначальная всё же ожидается, иначе, процитирую: а как тогда анонсировать фичи клиентам, заключать контракты... .
Хорошей практикой является, по возможности, давать оценивать задачи тому что ближе и лучше знаком с её контекстом, подводными камнями и у кого более полная картина о том что нужно вообще будет сделать.
Хорошей практикой является, по возможности, давать оценивать задачи тому что ближе и лучше знаком с её контекстом, подводными камнями и у кого более полная картина о том что нужно вообще будет сделать.
Да, но добавлю, что может быть и другой подход - оценивающий собирает подробности у тех, кто знаком с предметной областью, и строит план на основе этого. Почему так? Навыки планирования могут быть развиты у одного, а с предметной областью работает другой и за деревьями он не видит леса. Да и если проект крупный, то экспертов может быть несколько, а план в итоге один надо составить
Более того, в сложных окружениях задачи вообще ведут себя фрактальным образом: любой шажок, который изначально казался совсем маленьким и простым, может резко вырасти в размерах и стать едва ли не больше изначальной оценки всей задачи. А потом ещё один шажок, и другой...
Не все подводные камни удаётся находить заранее, хотя в целом практика очень полезная.
Некоторый инструментарий все же у нас есть и на этот случай
Прототипирование. То есть некий дешёвый вариант проверить идею и увидеть проблемы или, наоборот, повысить уверенность и начать финальную реализацию
Ранняя интеграция, чтобы все компоненты можно было соединить как можно раньше и собрать фидбэк или вообще увидеть, что получается
100-процентной гарантии это конечно не даёт, но шансы на успех должно повысить. Я наверно дополню немного статью, спасибо
Какой же неудачный пример с самолетом…
Давайте по другому, я даю вам задачу, вам надо приехать в Мухосранск и привезти 25 кг груза с собой, и ресурсов даю 10к рублей, и теперь задам вопрос «когда будет готово?»
Неизвестно летают ли самолеты в Мухосранск, сколько стоят билеты, сколько за багаж, есть ли самолеты рядом с Мухосранском и сколько там стоит и как оттуда добраться до Мухосранска, а может проще вообще на машине своей доехать…
Хорошо, что Вы приводите контрпример. Но является ли Ваш случай обычным или скорее исключением? У любого подхода есть область оптимального применения, и есть ограничения. Я указал это в статье:
Да, существуют проекты, в которых гораздо больше неизвестных
В Вашем примере с городом N надо собрать больше информации, например, связаться с кем-то из его жителей. В данном случае это и будет эксперт по проблеме, подскажет Вам варианты, как добраться. На основе этой информации построите план.
Любо провести эксперимент или серию экспериментов. Это подход, который предлагается для запутанных систем по модели Кеневин. Серия экспериментов не вписывается в бюджет, поэтому давайте лучше уточним информацию у жителей города N
По личном моему опыту, это как раз обычный пример любого разработчика выше уровня middle.
В данном случае это и будет эксперт по проблеме, подскажет Вам варианты, как добраться. На основе этой информации построите план.
Хорошо. Вы построили план, согласовали его и потом выясняется что
* груз быстро-размораживаемый
* его нельзя везти самолетом по санпин нормам
И да, это выясняется уже во-время выполнения плана. И все прогнозы "когда это будет готово" уже не работают :)
Примерно в таком мире живут разработчики.
Я сознательно не беру здесь примеры с простейшими задачами, которые можно поставить на конвейер.
Если работа связана с транспортировкой грузов, то наверно участники процесса должны знать, что существуют разные виды грузов со своими требованиям. Это часть профессии. В варианте, когда сегодня маляр, завтра экспедитор, потом кто-то ещё действительно будет много не учтенных рисков и план не сработает.
Что дальше? Исполнитель на полпути сломает ногу и из этого надо сделать вывод, что планирование не работает?
Я предложил способы, которые работали на разных проектах, в разных компаниях. Такого опыта, как Вы описываете, у меня не было. Бывало всякое, но как-то находились варианты.
Как Вы сами справляетесь с такими трудностями?
А как можно оценить время на разработку?
Проект в целом может быть новым для вас, но при этом состоять из частей, понятных для оценки.
Очень расплывчато. Что значит "понятных для оценки". Если речь про транспортную логистику, то всегда можно открыть карту с дорогой и вычислить путь с точностью до километра, можно посмотреть статистику по пробкам. А если разрабатывать программу - то карты нет! Что бы открыть код и сказать "ваша хотелка будет реализована через такое то время" понадобиться ... время. И, как показывает практика, "время на оценку времени" сопоставимо с "временем реализации" хотелки.
Иногда слышу "но, ты ведь делал что то подобное? давай будем считать, что время будет такое же". Но, если добавили какую то фичу для одного места программы (например, для документа определённого типа), абсолютно не факт, что это время будет как то сопоставимо с добавлением такой же фичи для других места программы. В других местах программы реализация такой же (с точки зрения пользователя) фичи может по сложности (и по времени) быть в разы больше или меньше.
Это хорошее замечание. Возможно стоит пересмотреть архитектуру или дизайн кода, если текущая реализация не соответствует новым требованиям. Я думаю, что это обычная история, когда существующую кодовую базу надо переосмыслить
То есть если ситуация, описанная Вами, повторяется регулярно, то это может быть симптомом.
Это я без всякого сарказма, если что. Сам регулярно сталкиваюсь с тем, что оценки по какой-то части продукта хронически неверные. Это повод подумать над рефакторингом
Из всего вышесказанного так и не понял:
А как можно оценить время на разработку?
Есть какая то чёткая методика - как взять код, и узнать время его исправления? На мой взгляд - такой методики нет. Есть только два пути - гадание и разбор кода. Анекдот помните - за постучать 5 копеек, а за то, что знать, где постучать - 5 рублей. Вот разбор кода, это, по сути, и есть выяснения места, где именно надо постучать.
И да, метод "гадания" очень нравится руководству.
Но разве сделать проект более понятным и надежным для планирования - не задача команды?
То, что Вы описываете - это распространненая ситуация, я согласен. Но помимо проблем с планированием это еще приводит к ряду неудобств - сложно онбордить новых людей и сложно делать изменения, потому что могут быть неочевидные связи и побочные эффекты.
Ваш вопрос про конкретную ситуацию - вот есть задача (что сделать), сколько это займет времени? И я с Вами согласен, что в условиях проекта, где настолько большие затраты на анализ кода, что-то планировать сложно. Мой ответ в том, что надо делать проект удобным для всех аспектов работы - планирования, внесения изменений, расширения функцоинальности, тестирования, отладки, релиза. И чтобы нетиповые случаи постепенно становились типовыми, то есть снижать сложность проекта.
Проблема точной оценки заключается в отсутствии понимания двух вещей: как выглядит бизнес-процесс и как он сейчас реализован в конкретно взятой системе со всеми её нюансами, которую нужно поправить. Это и есть контекст задачи. Если вы полностью знаете контекст, то легко дадите хорошую оценку по срокам, прям как в примере с самолётами.
В идеально-простом случае, если программу писал один человек с самого начала, он легко даст оценку, так как знает весь контекст. На практике - писал один, потом после него ещё 10 человек и все они давно уволились унеся с собою то самое, ценное понимание контекста. Документацию, естественно, никто не писал. В итоге имеем черный ящик. И вот как оценивать такую задачу, если вы новонанятый разработчик в этой конторе?
С этим можно бороться по разному:
Описывать бизнес-процессы, чтоб в первую очередь, сам бизнес знал, какие у него есть процессы, как они должны быть устроены и как их нужно модифицировать.
При разработке в приоритете всегда должна быть простота. Каждый лишний слой абстракции - это сильное усложнение (сложность растёт: n^n).
Писать сопроводительную документацию и комментарий в коде на будущее, чтоб при увольнении разрабов, ценный контекст не утекал безвозвратно вместе с ними. Написать документацию к коду после решения задачи стоит 1$, а чтоб потом восстановить весь контекст новому разработчику без помощи и подсказок будет стоить: n^n$.
Ну и на самом деле есть много разных способов и технических решений, как можно бороться с ростом сложности и "утиканием" знания контекста из компании. В терминальном случае, если вы не справитесь и раздуете сложность до неподъёмной, придется "переписать всё с нуля", заплатив кучу денег и скорее всего обанкротившись.
Когда это будет готово?