Комментарии 67
Ложь по определению требует, чтобы сторона, которая ее говорит, знала, что она говорит неправду.
Разработка ПО — это исследование
Ну если вы бросили универ на 2 курсе и вообще пошли учиться чтоб откасить от армии и переехать в город побольше - да. А для всех остальных это просто "набрать код слепой печатью". Как все живут нормально, но только в стране с самым лучшим в мире коммунистическим образованием и заряжателями бутылок у телевизора, опять всё какие-то исследования.
Скрам это калл.
...стране с самым лучшим в мире коммунистическим образованием и заряжателями бутылок у телевизора...
/sarcasm_mode on
Речь, видимо, про США, не знал, что там коммунизм.
/sarcasm_mode off
FYI, автор оригинала - Jason Godesky, закончил University of Pittsburgh.
А для всех остальных это просто "набрать код слепой печатью".
Я так понимаю, что вы hello-world'ы пишете?
сразу мне вспомнилась притча о мухе и шмеле. очевидно, комментатор — муха, да еще и без одного крыла, к тому же.
Ну почему же сразу все оценки - ложь? Оценка сроков "от нуля до бесконечности" звучит довольно правдоподобно. Я бы еще добавил, что иногда проблема в том, что вместо того чтобы взять решение задачи, которое мы знаем, мы создаем другое решение, потому что это интереснее, и якобы правильнее (я вот регулярно так делаю). )
Неплохие мысли поначалу, но потом в такой догматизм и невежество скатывается, что читать противно. Не удивлюсь, если автор оригинала из тех, кто за серьёзные килобаксы помогает серьёзным дядям "внедрить скрам в сжатые сраки(с)"
Но, вцелом, если брать адекватное и технически подкованное начальство, то оценки нужны не для планирования ресурса, а для приоритизации. Руководителю ведь, как правило, нах не надо выполнить таски 123, 456 и 789 в следующую неделю (за исключением багов на проде или безальтернативных внешних обстоятельств). Ему надо поднять вовлеченность, или уменьшить отток, или заинтересовать новых клиентов и так далее. Ему надо пройти из точки А в точку Б в бизнесе, и, как правило, есть тысячи способов сделать это, а задачи в беклоге это лишь одно из предположений, как. И, поэтому, получив оценки на варианты достижения точки Б от разработчиков, руководитель может оценить, а действительно ли ему надо именно эта таска выполнена, или подойдёт альтернатива, которая приведет бизнес в Б', который не сильно хуже Б, но требует в 3 раза меньше ресурса
Ещё оценки нужны для манипуляций в стиле "вы же мне обещали за три недели выкатить фичу на прод... поэтому в пятницу вам вместо пиццы устроим овертайм до победного деплоя"
Если надо пройти из точки А в точку Б оптимальным маршрутом, то задача и должна так ставиться. Выбор способа из тысяч - тоже часть решения задачи. Зависит наверно от задачи, но я думаю что вовлечение менеджмента в процесс выбора - это микроменеджмент
Оно то звучит красиво на практике, но, объективно, есть решения уровня программиста, а есть решения уровня продакта/руководителя. К примеру, если в системе есть race condition, и точкой Б есть его отсутствие, то, да, как его избежать, - пусть решают программисты. Но вот, выбирать между тем: исключить его полностью, потратив 2 недели, увеличив клауд кост на $1000/мес за счет усложнения архитектуры и добавив вероятности новых багов, или уменьшить его вероятность в 10000 раз, потратив день на хитрожопый патч, - это уже решение не программиста, увы. Для решения этой задачи надо обладать тем контекстом, который программисту просто невозможно знать (ибо фокус и объем внимания ограничен)
Не каждое программирование это исследование, конечно, если вы создаете что-то принципиально новое, как пример с тем же лекарством от рака, то да. Но в современных реалиях 80% и более - программирование это написание похожего кода.
В любой работе, где есть отхождение от рутины, будет элемент исследования, а все остальное рутина.
Ничего нового статья не привносит, кроме попытки из программистов сделать особых людей с особыми правами.
Так рутины в программировании почти нет. Пусть надо сделать X. Если X никто ранее не делал, то это - исследование, сколько займет времени - неизвестно. Если надо сделать X второй раз - то выполняется копипаст. Опыта копипаста X нет, понятно только то, что он будет выполнен быстрее, чем в первый раз. Если надо сделать X в третий раз - то выполняется рефакторинг и автоматизация выполнения X. Сколько времени на это нужно потратить - тоже неизвестно, потому что опять, задача "автоматизировать X" решается впервые. В четвёртый раз делать X никто не будет, потому что уже налажена автоматизация, и оно делается само.
Если надо сделать X в третий раз - то выполняется рефакторинг и автоматизация выполнения X
Если стоимость рефакторинга / автоматизации на 1-2 порядка превышает стоимость выполнения X, то автоматизация просто может оказаться нецелесообразной на текущем этапе (например, без понимания востребованности продукта на рынке). Также бывает, что для автоматизации нужны какие-то дополнительные ресурсы / технологии, которых сейчас нет.
Так что в теории все красиво, но на практике рутинные задачи встречаются довольно часто.
Полностью солидарен, если я - исполнитель.
Категорически не согласен, если я - заказчик. Заказчику нужно знать ответы на вопросы "сколько" и "когда".
При этом не стоит считать, что софт - это прямо сложно и непредсказуемо, а, например, строительство - просто и прогнозируемо. Наивно недооценивать сложность реального мира.
Недавний пример: нанял рабочих выкопать канаву на даче. Это даже проще, чем класть кирпичи, не так ли? По логике, каждый следующий метр канавы - он такой же, как предыдущий? Так-то оно так, но ровно до того момента, как рабочие уткнулись в закопанную груду кирпичей.
Не надо считать разработку - чем-то особенным. Другие области ничем не легче. А зачастую - сложнее и менее толерантны к изменениям. Если вы строите 10-и этажный дом, вы не можете посередине строительства передумать и построить 20 этажей. Каким бы гением не был ваш архитектор. А если вы строите софт, и у вас толковый архитектор, то добавить в 2 раза больше функционала, или в 2 раза увеличить нагрузку на систему - можете. Это будет стоить времени и денег, но - можете.
Возвращаясь к оценке. Если считать оценку не числом, превращающимся в обязательство по факту его озвучивания, а функцией распределения вероятности - то она вполне имеет право на жизнь.
И если вы хотите прозрачности, то накопите статистики, расскажите бизнесу азы "тервера", управляйте рисками и работайте.
Ваш бизнес не хочет слушать и требует одно число? Сочувствую. У меня такое регулярно. Качайте ораторское мастерство. Закладывайтесь со сроками по 90-му или 95-му персентилю (если хватит наглости) Или меняйте бизнес. Ну или фрустрируйте и пишите статьи о невозможности оценок.
Дополнительные +10 этажей - наверное, нельзя. Но есть куча примеров, когда к существующим домам достраивали этажи в количестве 1-2-3 штуки, и даже делали на крыше какой-нибудь бассейн (который куда тяжелее обычного этажа).
можно все. снес и построил с 0. в начале 90х когда только начинал программировать было несколько раз что готовый на 90% проект полностью переписывал с 0. причем тогда у меня еще не было своего компа дома и код turbo pascal + turbo vision я писал на тетрадных листах и быстро вбивал на рабочем компе... с возрастом лень тренирует навык построения более грамотных фундаментов и сносить в 0 уже не надо и лень :)
Если вы строите 10-и этажный дом, вы не можете посередине строительства передумать и построить 20 этажей. Каким бы гением не был ваш архитектор.
То есть?
Все возможно. Но это может стоить разную сумму, из которой основная часть - это фундамент. Если он может выдержать нужный вес, то укрепить текущую часть и достроить - дело техники. У меня есть даже живой пример как комплекс 12-24-12 этажей переделали в 24/24/24/24 уже тогда, когда первые 12 были построены.
ну собственно в данном случае аналогия практически буквальная. "фундамент" в разработке ПО это то что называется архитектурой: базовые решения об устройстве ПО, принимаемые в самом начале проекта. Он обеспечивает некоторую степень прочности, благодаря которой можно "достраивать этажи". Или нельзя.
Хороший пример, но я бы не стал покупать квартиру в этом доме.
У меня есть даже живой пример как комплекс 12-24-12 этажей переделали в 24/24/24/24 уже тогда, когда первые 12 были построены.
Есть подозрение что такая перестройка была запланирована заранее. Так иногда делают чтобы обойти нормы по застройке.
Да, мне во всяких корпоративных жирах не хватает дать оценку в виде нормального распределения "1 день ± 4 часа" или "1-2 дня".
Можно, конечно, по верхней границе оценивать, но это чревато непониманиями с другими людьми, кмк.
Если вы строите 10-и этажный дом, вы не можете посередине строительства передумать и построить 20 этажей. Каким бы гением не был ваш архитектор. А если вы строите софт, и у вас толковый архитектор, то добавить в 2 раза больше функционала, или в 2 раза увеличить нагрузку на систему - можете.
Построил прапорщик взвод солдат: Так, бойцы. Будете копать яму 3х3х3!
Один из солдат: А может быть лучше 3 ямы 1х1х1?
Прапор почесал репу: Ну, ладно. Пусть так. Занимайтесь.
Вы правы, реальный мир нельзя недооценивать. Но все же, программирование качественно отличается от, например, строительства. Возможности по переиспользованию ранее решенных задач в нем гораздо выше.
К разработке ПО можно относиться как к искусству, ремеслу, инженерии. Если речь о коммерческой разработке приложений, то предпочтительнее третий вариант (использование паттернов ООП, высокоуровневых паттернов, спецов, набивших руку на подобных задачах). Этап исследования в этом случае может быть в проекте; но как этап предваряющий производство (кодинг). Методология может быть любой, главное - использовать объективные/измеряемые/проверяемые данные/показатели, а не частные мнения/оценочные суждения. По комментариям выше, вижу, что смешиваются понятие "программирование" и "проектирование". Разработка (development, "развитие") - это и первое, и второе (сначала проектирование, конечно). В общем, в названии статьи пропущены слова "на практике" между "... ПО" и "- ложь".
В каком-то смысле эта статья - эталон. Эталон непонимания того, что есть профессия программиста.
Начнем с середины: "Каждый кирпич обычно очень похож на любой другой, по крайней мере, в том, что важно при строительстве стены. Количество времени, необходимого для укладки всех кирпичей, в общем случае довольно близко ко времени укладки одного кирпича, умноженному на количество кирпичей" - почти любой программист использует в своей работе библиотеки. Библиотеки - это те же самые кирпичи, которые надо сложить вместе и соединить кодом, чтобы получить стену. Если программист не может сложить из имеющихся "кирпичей" стену - это не программист. Равно как каменщик, который с точностью до килограммов не может назвать объем раствора, чтобы построить стену из имеющихся кирпичей - не каменщик.
Хорошо, идем дальше - "Почти всё время разработки тратится на новые задачи, ответов на которые мы не знаем. Часто они новы ужасно скучным образом, например, «как нам сохранять эту модель данных с этими конкретными полями в эту конкретную базу данных?» Но именно из-за них эта ситуация отличается от всех остальных (или, по крайней мере, от тех, которые мы смогли найти) и именно это занимает всё наше время" - нам дали десять (двадцать, сто) камней, чтобы сложить стену, но мы не знаем, как это делать - и это нам говорится открытым текстом и преподносится, как откровение свыше. "Разработка ПО — это исследование" - ребята, вас обмвнули: исследованием является только создание нового "кирпича" (нового алгоритма). Все остальное является ремеслом. "как нам сохранять эту модель данных с этими конкретными полями в эту конкретную базу данных?" - лично я гнал бы за такой вопрос даже джуна. С объяснением "учи кирпичи!"
А потом идет кромешный ужас под названием agile/scrum. Если при проектировании системы были допущены огрехи, то их иногда можно исправить. А иногда проще переписать с нуля. И никакими еже...ными митингами ничего не сделать.
Короче: работа программиста состоит в том, чтобы реализовать заданный в ТЗ алгоритм. Разработкой алгоритмов занимаются, как правило, другие люди. Срыв дедлайна - ЧП.
Короче: работа программиста состоит в том, чтобы реализовать заданный в ТЗ алгоритм. Разработкой алгоритмов занимаются, как правило, другие люди. Срыв дедлайна - ЧП.
А теперь представьте, что ТЗ нет, алгоритмов тоже нет, профильные специалисты также отсутствуют. Есть только абстрактная задача сверху.
Есть и такое. Но, это вообще не о программировании и не о разработке ПО. Как правило, должность человека, решающего столь абстрактные задачи, называется CEO, COO, General Manager, или, хотя-бы, Head of business unit, и подразумевает, что человек хотя-бы на очень базовом уровне понимает оперирование, маркетинг, финансовое планирование, управление персоналом, ИТ одновременно. Ибо помимо написания кода есть масса способов решить абстрактную задачу (например, приобрести доступ к сервису, исполняющему код у того, кто его уже написал и почистил от багов, или, нанять и обучить 10 студентов, которые все отлично сделают в Excel).
Если уже дошло до привлечения к процессу программиста, и было принято решение, что абстрактная задача решается именно разработкой ПО, значит, как правило, таки да, ждут именно реализации алгоритма, иногда, к слову, описанного не императивно, а декларативно (составь маршрут для курьера, чтобы он развез все посылки, потратив минимум бензина). И, таки да, если мы не говорим о компаниях, которые изобретают новые кирпичи (как open ai), то, и ожидается при этом, что программист именно и возьмёт готовые кирпичи и соединит их предсказуемым способом, а, если таких кирпичей на рынке нет, то тот час же сообщит об этом, и уточнит, действительно ли ему готовы платить за потуги для изобретения нового кирпича за неопределенное время с неопределенным результатом, или же, лучше подумать над более конкретным заданием
Пример - к вам приходят с задачай - реализовать какую то функцию который на данной момент в программе нет.
Вариант 1 - вы знаете наизусть все 1.5 миллиона строк кода приложения и их текущее состояние, ваши знания о механизмах и библиотеках исчерпывающи и абсолютны -
В таком случае вы за вычисляемое время легко дадите оценку задаче, и скорее всего в неё даже попадёте, если не будете зависит от сторонних сервисов.
Вариант 2 - вы не знаете весь код наизусть. - тогда вы можете потребовать время на оценку - неопределённое время, потому что вам нужно пересмотреть все затрагиваемые места, убедиться что там "всё стандартно" или "что-то не стандартно", перечитать документацию по каким то библиотечным местам, понять какой код куда и зачем нужно вписать. В этот момент вы сможете дать довольно точную оценку, правда фактически зачастую может получиться что вы сначала потратили 2 дня на оценку а потом оценили в 15 минут, и точно попали. Если же время на оценку зафиксировать (например 2 часа), то точность попадания в оценку будет падать пропорционально времени которое непотраченному на исследование.
А если к этому примешиваются сторонние сервисы - а обычно компонентов штуки три - фронтенд, бэкенд, биллинг, то в точность оценки добавляется еще и их влияние, которые вы не можете учесть.
Конечно, бывают и приложения, где один и тот-же человек делает одну и ту-же задачу достаточно часто - чтобы для него всё было очень предсказуемо. Например если вы занимаетесь исключительной вёрсткой страниц ошибок, которые немного отличаются дизайном, положением текста об ошибке, и количеством возможных кнопок. Или исключительно добавлением новых форматов товаров, которые отличаются только набором полей но для каждой 2 маппера и 1 вариант отображения в фрейме фиксированного размера. В таких случаях оценки отлично работают и довольно точно отражают истину - но проекты где такое происходит редки, да еще и зачастую - бизнес логика их не содержит необхоидмости в этих дейсвтиях - они являются следствием архитектурной ошибки, которая привела к необходимости выполнять одну и ту-же работу многократно вместо переиспользования.
Горячо пожимаю вам руку, коллега!
Полностью согласен.
В мире уже давно определили две совершенно разные деятельности:
1) Программирование - это специальность (computer sciences, programming). Программист пишет - да хоть карандашём словами на бумаге - математику и алгоритм.
2) А вот наиболее распространённый "зверь" - это Кодер (coding), и это НЕ специалист, а рабочий.
Первый - примерно как архитектор/проектировщик, а второй - каменьщик/монтажник ;)
Увы, очень часто происходит грубое смешивание этих двух деятельностей со всеми вытекающими. А уж HR'ы так вообще как будто применяют random для описания вакансий)
Короче: работа программиста состоит в том, чтобы реализовать заданный в ТЗ алгоритм
Это не программист, а машинистка кодер
Разработкой алгоритмов занимаются, как правило, другие люди.
А вот это уже программист.
Разработкой алгоритмов занимаются, как правило, другие люди
В стране волшебных пони, у каждой специализированной задачи есть отдельный человек.
Аналитики пишут ТЗ, архитекторы говорят как его реализовать, девопсы настраивают рабочие процессы, менеджеры разбивают ТЗ на план, а программист просто берёт следующую задачу из списка, где всё подробно расписано.
Вот только в реальности всё это может делать один человек. Потому что нету ни девопса, ни аналитика, ни архитектора. Есть только менеджер, который договорился с клиентом, легаси код который как то работает, и сроки выполнения.
нам дали десять (двадцать, сто) камней, чтобы сложить стену, но мы не знаем, как это делать... "учи кирпичи!"
Между двадцатью и ста есть разница.
Ради интереса, попробуйте оценить: сколько времени у вас займет собрать пазл из соответствующего количества плиток? Здесь ведь даже учить ничего не надо - просто собрать. А потом реально собрать и порефлексировать над результатами.
Чтобы ещё больше приблизить игру к реальности, попробуйте предварительно смешать плитки из нескольких однотипных наборов. Просто в конце покажете несколько картинок, сложенных рядом.
Половину из них раздайте детям - с условием, чтобы они все вернули ровно через час. Оставшейся половины вам ведь точно должно хватить, чтобы не сидеть без дела всё это время?
Да, кто-то из детей потом может опоздать. Кто-то в процессе потеряетет какие-то детали, но чтобы не огорчать отца, заменит на примерно похожие. Поэтому разницы сразу вы не заметите. Но в конце результат у вас все равно должен быть как на макете.
Теперь снова прикиньте оценку. А может вам хватит простого коэффициента?)
Ещё труднее объяснить, что проект всё, мертв, хватит пинать мертвую лошадь. Некоторые менеджеры просто в это не могут поверить.
Думаю в статье никак не рассмотрен момент, который крайне сильно влияет на сроки - а именно "мотивация". В нашей стране принято мотивировать некоторой "грамотой", которая нафиг ни кому не нужна. А если в качестве мотивации будет, к примеру, автомобиль, да причем не одному, а каждому - наверняка будет и результат. К сожалению любое руководство предпочитает не тратить лишних денег "на холопов", а мотивировать только путем "наказания" - что естественно обрекает практически любой проект на провал. В лучшем случае, в случае успеха раздают "подарки" - какие-нить чехлы к телефонам, коврики к мышкам - в общем бесполезное фуфло
Я работаю в Японии в бодишопе, и хотел бы рассказать, как на моем примере обстоят дела с разработкой в Японии.
Я как-то однажды об этом уже писал: в Японии разработка ПО, по сути, относится к сфере услуг, со всеми вытекающими. Помните знаменитые фразы "покупатель всегда прав" и прочее? Вот тут это возведено в абсолют, из-за азиатского менталитета "угодить покупателю заказчику любой ценой". И сроков это тоже касается. Твой менеджер спрашивает у тебя сроки, но они всегда упираются в "сделаем максимум за месяц", потому что заказчик имеет свое расписание, а дополнительных людей на проект выделять никто не будет. Также стоит держать в голове, что сторонними библиотеками почти наверняка пользоваться нельзя, ибо заказчик скорее всего не захочет возиться с лицензиями - так что никаких "кирпичиков", как пишут некоторые. За множество однотипных проектов собрал свои наработки в библиотеку? Тебе не разрешат ее использовать в следующем проекте, потому что это лишняя dll, хотя никаких причин для этого нет - разве что "заказчик может не захотеть", о чем заказчика менеджер на самом деле спрашивать не станет. Заказчик захотел 3д в приложении? Пиши на opengl с нуля. Ну как с нуля, приходится чуть ли не умолять менеджера, чтобы разрешил использовать glfw и glew (и то, представьте, когда вы сидите на митинге с заказчиком и менеджер заискивающим тоном сначала неловко спрашивает об этих 2 библиотеках, и тут же оговаривается, что в принципе можно обойтись и без любой из них, если заказчику "неуютно"). Когда тебя спрашивают почему ты хочешь их использовать - отвечаешь резонное "потому что имею опыт работы, в 3д-области это важно" - и тебе менеджер делает замечание, что так заказчику говорить нельзя, мол, я навязываю тем свой выбор... В общем, нельзя беспокоить заказчика, а точнее - как либо потенциально обременять. Чтобы вы понимали специфику - в Японии работники сферы услуг вечно кланяются и благодарят покупателей-посетителей за любой чих, и даже извиняются за то, что просто оказались на пути вашего взгляда до нужной вам полки с товаром. И вот подобное поведение проецируется и на разработку. Даже если это поведение вредит результату. Еще раз уточню - я не говорю за всех, но когда на корпоративах спрашиваешь у местного начальства, они утверждают, мол, это нормальный подход в японских компаниях.
Дык и как вы выкручиваетесь?
Так как по сути сроки решают за меня, я просто делаю задачи в обычном для меня темпе и в большинстве случаев успеваю. Нередко мне удается подвинуть сроки только лишь потому, что мои навыки все же ценят - просто кроме меня данную задачу мало кто сможет сделать так же быстро, ведь те, кто сможет - в таких конторах надолго не задеживаются.
Любая оценка, даже с большой погрешностью, лучше, чем ее отсутствие.
Не попадание в оценки - это нормально.
Рефлексировать и устранять промахи в оценках - это необходимость.
Нельзя строить долгосрочные планы без каких либо оценок.
Ни один нормальный проект не будут начинать, не попытавшись оценить сроки.
А вообще, это звучит, как, "еще 100500 отмазок, почему мы не хотим оценивать сроки".
Автор привел кучу причин, почему он этого делать не хочет и ни одной, почему это важно делать. Отмазка джуна, к которому пристает ПМ.
Исследование это когда: а если я напишу так, что получится? А если я напишу по-другому, что получится? а если вообще ничего не написать, что получится? Разработка и исследование это разные вещи.
Когда задача типовая(сайт визитка), то какие-то сроки можно называть. Когда что-то непредсказуемое, то пытаться давать прогноз, но договор за время работы, а не за проект. Фиксированное время разработки это фиксированная стоимость и аффективные менеджеры будут стараться сдать в срок(а лучше на пару месяцев раньше чтоб премию получить) Мне еще не удалось угадать время. Заставляю себя умножать время на 3, но всеравно не хватает.
Для большинства разработчиков ПО оценки сроков — это ложь
Тебя напрягает, что ты можешь нечаянно соврать о сроках, меня напрягает, что я могу случайно сказать правду. Мы с тобой на разных уровнях.
Я уверен, что большинству из вас приходилось перерабатывать и трудиться по ночам, чтобы уложиться в дедлайн
Ещё чего. Просто за день-два до конца спринта говорю, что не успеваю, задача переоценивается, при необходимости дробится, и вставляется в следующий спринт. В 17:59 крышка ноутбука хлопает вне зависимости от статуса.
Акции рушатся. Сотрудников увольняют.
Обожемой, как хорошо что что я не покупал акции своей компании. Ну уволят и уволят, финансовая грамотность как раз о том, чтоб увольнение пугало меньше, чем пустой рулон туалетной бумаги дома, а не о том как рефинансировать кредит на 20 лет ))
Вы можете услышать раздражённое «Не понимаю, почему нужно так много времени»
Главное не вступать в вялотекущее противостояние, увидел раздражение - не сдавай позиции, пытаясь сгладить конфликт и убедить логикой. Вы проиграете. Это его работа убеждать людей подписаться на невыгодных условиях, а заполучив устный контракт придавить вас взятыми обязательствами.
Тому, кто так говорит предлагаешь сесть и сделать за меньшее время, пока ты его менеджерскими задачами займешься)) Почти любого мелкого начальника довольно сильно выбесит даже такой безобидный формат. Сразу же всплывёт его некомпетентность в продукте и посредственные софт скиллы. Есть какой-то шанс, что уволят именно тебя, но так ли тебе надо место с овертаймами и некомпетентными менеджерами?
Что могу сказать по поводу статьи. Автор явно забывает что помимо дизайнеров, разработчиков и тестировщиков как правило команда состоит ещё Менеджера, Аналитика(ов) (Бизнес и системный). Чтобы начать прогнозирование, Менеджер изначально топает к аналитику и да, на раннем этапе сроки могут быть неточные, но по мере аналитики вполне с высокой точностью можно определить сколько потребуется разработке и дизайну на внедрение соответствующих фичей.
Хотел ещё написать, что итерационное планирование на тех же груммингах задач позволит достаточно близко попасть точно в глобальных сроках. В конце правда вспоминается про scrum подход.
Вообще главная задача менеджеру это подобрать адекватный множитель к срокам (не забываем, что те же сторипоинты вполне можно перевести в сроки по средней производительности команды)
Что по итогу, некоторые мысли в статье в целом верные, но излишнее утрирование и догматизация ведут явно куда-то не туда
Вообще главная задача менеджеру это подобрать адекватный множитель к срокам (не забываем, что те же сторипоинты вполне можно перевести в сроки по средней производительности команды)
Ещё бы неплохо помнить, что это не множитель, а, скорее, нелинейная функция. Что-то вроде "таск на 1сп = 4часа", "таск на 3сп=16часов", "таск на 8сп=80часов", "таск на 13сп= задача неясна, декомпозируй и оценивай заново, а то за все разумные сроки вылетишь".
Имею скромное мнение о сроках.
Часто эти сроки требуют ушлые менеджеры, которые смутно понимают специфику работы вообще, код и в глаза не видели, не то, что писали - им просто надо отчитаться.
Им кажется, что так они будут "меньше корову кормить и больше ее доить", что программисты ленивые и будут тогда работать. Часто это люди сами весьма необязательные и ненадежные - судят по себе.
На практике, оказывается, что сроков вообще никаких не нужно было, а программисты, как люди люди ответственные при этом сидят на нервах, потому что "ну я же обещал".
Вместо того, чтобы потратить лишние 5 минут на спокойное чтение документации - начинают гнаться, чтобы успеть.
А потом эта срочная "фича" лежит еще 2-3 недели просто так. Вопрос - с чего бы вдруг, надо же было срочно?
Раньше работы была такая, что это было часто - у меня это вызывало стойкое желание встать и послать всех. Предложить уважаемым менеджерам самим сесть и сделать.
Если в компании такие менеджеры, которые не могут осознать даже, что сделать табуретку и разработать новый самолет - это разные вещи, то надо просто напрямую об этом сказать главному руководителю.
Если руководитель адекватный, он объяснит менеджерам, если нет - просто уйти.
Лучше так, чем постоянный нервяк 24/7, потому что надо сделать "внезапно".
Я через это проходил и как программист с в самом начале, и как руководитель уже большой группы людей - больше ни за что не соглашусь на подобное
Известно, что Альберт Эйнштейн любил на досуге колоть дрова, посвящая этому делу не один час.Когда его спросили о причинах любви к такому занятию, он ответил, положив топор рядом с очередным поленом и утирая пот со лба:- В отличие от всех остальных моих занятий, эта деятельность позволяет мне сразу увидеть результат.
Я называю это наркомания - стремление получить удовлетворение как можно быстрее. На это подсаживаешься, это вызывает привыкание, отсутствие быстрых результатов приводит к ломке и даже - выгоранию. В таком состоянии люди готовы буквально на всё, чтобы получить очередную дозу своего удовольствия сию секунду, даже на преступление.
Когда менеджеры требуют оценку немедленно, программисты коммитят код без тестов, чтобы закрыть задачу, а тестировщики красят в зелёный неглядя - вот это оно.
Я точно так же люблю мыть посуду, да. :D
Для тех, кто у вас спрашивает оценки, а потом назначат их же вам как дедлайны - наверняка в аду приготовлен отдельный котёл.
Вообще задачи условно делятся на две категории. 1. Которые понятно как делать. 2. Которые - не понятно.
Задачи первого рода есть всегда и вы можете дать для них оценку с большой долей достоверности. Так сделайте это.
Если столкнулись с задачей второго рода, то положите в спринт спайк с задачей на исследование, и целью - родить план для дальнейших действий, которые уже сможете оценить. Установите на нее психологически и финансово комфортный лимит по времени сверху. Все у вас снова есть вполне правдоподобная оценка.
В итоге все задуманное либо будет оценено и выполнено. Либо вы от чего-то откажетесь, если сочтёте нерешаемым. Но у вас для этого уже будут все основания.
Боже ж ты мой. обычно проговорив с программистами сроки и умножив это всё ровно на два ты практически всегда укладываешься в запланированные тобою сроки разработки.
согласен. сколько не считай время а реальность под ручку с неопределившимся заказчиком всегда найдут способ засунуть конус неопределённости в анус планирования
На самом деле, практически при любом прогнозе сроков завершения дела, основанного на не свершении вероятных событий есть в том или ином роде лукавство. Ответ по срокам от одного дня (часа) до никогда будет максимально честным, но действительно не верным в некоторых ситуациях.
По этому верный вопрос по срокам будет что необходимо сделать и чего избежать чтобы это сделать за одну неделю (один месяц). Только задавать нужно не когда это нужно было вчера.
Подход "тыж программист" порочен своей психологической манипуляцией " ты же умный, сообразишь как справиться и обязательно справишься".
Привет всем.
Постоянно получаю ссылки на подобные статьи от руководства, hr, “снизу, сверху, сбоку” и т.п. Надоело быть просто читателем, а тут немного “подгорело”, что называется. Решил зарегистрироваться и написать.
Почему - не знаю, долго думать. Наверное, просто эмоционально перегружен и вспомнил, что такое форумы. А вдруг найду людей, с кем можно конструктивно обсудить понятия и что-то позаимствовать - последнее честно, идеи иногда кончаются ?.
Не буду делить продукты, проекты, продажи и т.п. Не буду говорить, что мы не обманываем себя сроками и т.п. Вообще это философия, истина только одна, и вы все ее знаете :)
Как оно бывает на практике, вы тоже знаете.
Выше писали
Ну почему же сразу все оценки - ложь? Оценка сроков "от нуля до бесконечности" звучит довольно правдоподобно. Я бы еще добавил, что иногда проблема в том, что вместо того чтобы взять решение задачи, которое мы знаем, мы создаем другое решение, потому что это интереснее, и якобы правильнее (я вот регулярно так делаю). )
Эти слова навели меня на вопрос, как не выдумать новое, потому что оно “интереснее”? Никак.
Есть маркетинг, внутренний, внешний, есть внешний бизнес-заказчик, есть целые сферы бизнеса, чей поток сознания выливается на ”внедренцев” и ”продуктовиков” каждый день :-).
“Интересное” порождает запросы - запросы мы решаем, не все можно собрать из кирпичей, но иногда можно. У нас есть работа - спасибо, интересная - да.
Неплохие мысли поначалу, но потом в такой догматизм и невежество скатывается, что читать противно. Не удивлюсь, если автор оригинала из тех, кто за серьёзные килобаксы помогает серьёзным дядям "внедрить скрам в сжатые сраки(с)"
Но, вцелом, если брать адекватное и технически подкованное начальство, то оценки нужны не для планирования ресурса, а для приоритизации. Руководителю ведь, как правило, нах не надо выполнить таски 123, 456 и 789 в следующую неделю (за исключением багов на проде или безальтернативных внешних обстоятельств). Ему надо поднять вовлеченность, или уменьшить отток, или заинтересовать новых клиентов и так далее. Ему надо пройти из точки А в точку Б в бизнесе, и, как правило, есть тысячи способов сделать это, а задачи в беклоге это лишь одно из предположений, как. И, поэтому, получив оценки на варианты достижения точки Б от разработчиков, руководитель может оценить, а действительно ли ему надо именно эта таска выполнена, или подойдёт альтернатива, которая приведет бизнес в Б', который не сильно хуже Б, но требует в 3 раза меньше ресурса
Соглашусь с akakoychenko.
У нас это так. Вот мы погружены, вот мы знаем теорию, вот мы экологичны в общении. И что же из этого должно следовать?
А следует то, что мы не можем применить на практике идеально методологию.
Мы можем гибридизировать любую идею, чтобы достичь решения задачи. Далее условности, а не конкретные цифры, просто для простоты подсчета, или сложности. Не знаю. Это бизнес, это рынок, и цель одна, “не нужно себе врать” (с).
У продуктов свои проблемы
Бизнес хочет зарабатывать 5 млн рублей в месяц, ищет варианты, придумывает услуги, продукты (Условно объединил всех в бизнес)
Хочет, чтобы каждый рубль был потрачен эффективно
Еще чтобы это произошло ASAP
Он не хочет текучки и чтобы все были счастливы
Маркетинг хочет, чтобы было красиво, завлекательно
И т.д.
У проектов - свои.
Заказчик хочет заработать денег. Хотя тут чаще на чем-то сэкономить. Отказаться от дорогого и перейти на дешевое.
Купить что-то, чтобы оптимизировать и разогнать бездельников.
И т.д.
Везде нужно понять, сколько я, как торговец (назову так), потрачу, чтобы заработать. Вот и юзер стори. С другой стороны, я, как торговец, хочу сэкономить, для этого я заменю неповоротливую систему на современную, модную и т.п.
Сколько мне будет это стоить? Кто мне ответит на этот вопрос? Я выберу. Готов ли я потратить много? А сколько это много? Не врем себе, идем на рынок.
Торговец: кто хочет заработать?
Мы с вами: я хочу, и я хочу.
Торговец: кто может
Мы с вами: я могу, и я могу
Торговец: как же мне сравнить? (я сейчас не буду про тендеры и т.п.). Дайте-ка мне сумму и срок.
Можем мы ответить вилкой? Да, это компромисс.
Но уже и вилка сама по себе получается обман? Здесь можно хоть целую статью писать.
Если смотреть на это как на черное и белое, то возможно автор и прав. Как и любой теоретик прав. И такие взгляды нужны, чтобы был какой-то базис для размышления, внедрения в процессы, проверки гипотез и в итоге гибридизации.
Но на практике мы стараемся получить от этого прибыль в виде прямого дохода или экономии.
И как будто бы вывод один - не возводи в абсолют, думай головой, не верь слепо, а проверяй, применяй, анализируй, меняйся.
Спасибо за возможность выразить мысль.
Сплошной набор передёргиваний
Все оценки сроков разработки ПО — ложь