▍ Разработка ПО — это исследование
Требуют ли фармацевтические компании от исследователей сообщить им сроки создания лекарства от рака? Исследователи могут сообщить сроки выполнения конкретного исследования (и достаточно точные сроки, потому что планы исследований обычно имеют графики), но результаты наподобие «получения лекарства от рака» зависят от того, что выяснится в процессе экспериментов. Для прогнозирования подобных результатов нам заранее нужно знать результаты экспериментов, но если бы мы их знали, то эксперименты были бы не нужны. На самом деле мы не можем смотреть дальше, чем результаты следующего эксперимента, потому что этот эксперимент определяет дальнейший шаг.
В разработке ПО мы не тратим время на задачи, решения которых знаем. Если решения уже существуют, мы добавляем в качестве зависимости пакет или библиотеку с этим решением, или копируем старый код, или делаем что-то ещё, на что требуются секунды, а затем можем переходить к следующей задаче. Почти всё время разработки тратится на новые задачи, ответов на которые мы не знаем. Часто они новы ужасно скучным образом, например, «как нам сохранять эту модель данных с этими конкретными полями в эту конкретную базу данных?» Но именно из-за них эта ситуация отличается от всех остальных (или, по крайней мере, от тех, которые мы смогли найти) и именно это занимает всё наше время.
Разработка ПО почти полностью состоит из быстрого цикла экспериментов. У нас есть мысль о том, как мы можем решить задачу, нам требуется несколько секунд, чтобы написать решение, а затем мы его выполняем. Если это срабатывает, мы переходим к следующей задаче, если не срабатывает, то пробуем другую мысль. Когда у нас заканчиваются идеи, то мы переходим на Stack Overflow и пытаемся найти что-нибудь там. Клинические испытания могут длиться месяцами, а большинство экспериментов в разработке ПО занимают меньше минуты — это может быть быстрое изменение строки кода, проверка прохождения юнит-тестов или результатов при повторном запуске программ или перезапуске браузера. Наши циклы гораздо короче, но мы всё равно не можем предвидеть дальше, чем результат следующего эксперимента. Если он срабатывает, то мы решили задачу; если нет, то мы пробуем что-то ещё. Каждый разработчик ПО сталкивался с задачами, на решение которых требовались часы, но даже если вы зарылись в задачу с головой, в любой момент времени есть вероятность, что следующий прогон окажется рабочим. И вы никак не сможете узнать, сколько времени осталось до решения задачи, тридцать секунд или три часа, пока она не будет решена. Единственное, что мы честно можем сказать, так это что мы делаем прямо сейчас.
Чем больше у вас опыта в строительстве, тем точнее вы сможете оценивать сроки постройки стены, но это возможно, потому что все переменные известны. Это нелёгкая работа, но с точки зрения сложности задача остаётся простой. В процессе работы практически не возникает новых факторов. Каждый кирпич обычно очень похож на любой другой, по крайней мере, в том, что важно при строительстве стены. Количество времени, необходимого для укладки всех кирпичей, в общем случае довольно близко ко времени укладки одного кирпича, умноженному на количество кирпичей.
Но в разработке ПО всё совершенно не так. Разработчики ПО могут обманывать себя, считая, что с опытом они начинают лучше оценивать сроки (особенно если их мотивируют это делать), но поскольку мы тратим всё своё время именно на задачи, которые раньше никто не решал, то любой прошлый опыт, по определению, не имеет никакого веса. Если у нас есть подходящий прошлый опыт, то мы выполним задачу за минуты или даже за секунды. Почти всё наше время мы тратим на задачи, которые не решали раньше, на цикл крошечных экспериментов.
Разумеется, конус неопределённости существует. При нахождении решения новых задач остаётся меньше нерешённых, потому что неопределённость при решении десяти задач ниже, чем при решении десяти плюс ещё девяноста. С другой стороны, в задачах разработки ПО может быть сложно объяснить разницу между простым и практически невозможным, и это не всегда интуитивно понятно даже для опытных разработчиков. Иногда истинная сложность задачи вскрывается после её глубокого изучения. Да, есть вероятность, что когда осталось всего десять задач, неопределённость снижается, но любая из этих десяти задач может оказаться монстром, занимающим в два раза больше времени, чем предыдущие девяносто девять вместе. Конус неопределённости говорит нам, что это маловероятно, но мозг человека имеет ужасную привычку путать маловероятное с невозможным. Когда от этой привычки зависят планы проектов, то компании оказываются раздавленными разницей между этими понятиями.
▍ Смертельная цена обмана
Для большинства разработчиков ПО оценки сроков — это ложь, которую они рассказывают руководству (обычно потому, что руководство на ней настаивает). Хорошие разработчики противятся этому. Они пытаются объяснить, почему оценки бесполезны и не должны использоваться ни для чего. Но их руководство настаивает, что ему нужны оценки, поэтому разработчики говорят какие-то сроки, обычно с большим запасом для своей защиты и со множеством оговорок. В организациях с нездоровой культурой руководитель настаивает, заставляя разработчиков предоставить более сжатые сроки. Вы можете услышать раздражённое «Не понимаю, почему нужно так много времени» от того, кто точно не заинтересован неделями слушать лекции, необходимые для объяснения сроков. Даже в организациях, которые доверяют своим разработчикам, эти оценки становятся диаграммами Ганта и графиками проектов. Они быстро превращаются из прикидки в железное обязательство, на кону которого стоит работа людей.
В опросе Института управления проектами Pulse of the Profession за 2018 год говорится, что примерно 48% проектов не укладываются в дедлайны. Вероятно, большинство из нас это не удивит, но мы всё равно упорно верим в том, что это единственно возможный способ ведения бизнеса, несмотря на то, что успех или провал практически определяются броском монеты. Я уверен, что большинству из вас приходилось перерабатывать и трудиться по ночам, чтобы уложиться в дедлайн, даже если эти переработки приводили к снижению производительности и даже замедляли проект из-за внесения новых багов, требовавших больше времени на устранение, чем потрачено на «кранч». Есть кучи книг, доказывающих, что такая стратегия не только неэффективна, но и контрпродуктивна и требует от нас ещё больше времени, которого и так не хватает. Это было бы плохо само по себе, если бы это было плохой бизнес-практикой — к сожалению, компании принимают ужасные решения каждый день — но это ведь ещё и убивает каждый год 750 тысяч человек.
Но какого ещё результата нам следует ждать? Все оценки сроков — ложь, поэтому принятые на основании них планы и дедлайны проектов — это фантазии. Почему мы ожидаем, что их связь с реальностью будет точнее, чем бросок монеты? И чего мы ожидаем от людей, когда их жизнь зависит от этих фантазий?
Выше я говорил о том, что наши прикидки превращаются в железные обязательства; напомнить вам о третьей ценности из манифеста Agile-разработки ПО?
Сотрудничество с заказчиком важнее согласования условий контракта
Мы видим, что современный подход к согласованию условий контракта не соответствует ничьим потребностям: ни разработчиков, ни бизнеса, ни заказчика. Вспомним изложенный выше сценарий: руководитель спрашивает у разработчика оценки сроков, разработчик даёт отпор, а руководитель настаивает, что бизнесу для планирования нужны сроки. Давайте сделаем шаг назад и разберёмся, зачем бизнесу вообще нужны оценки сроков. На то есть несколько действительно весомых причин:
- Бизнес должен иметь возможность планировать ресурсы, обеспечивать эффективность назначаемых сотрудникам задач.
- Бизнесу нужно обеспечить координацию всего для выпуска большого продукта.
- Бизнес должен информировать высшее руководство и стейкхолдеров о текущем состоянии дел.
Однако в каждом из этих случаев ложность наших оценок создаёт запутанную паутину новых проблем, в конечном итоге приводя к провалу изначальной цели. Всё это очень важные цели, и их провал — серьёзная проблема. Единственный способ достичь этих целей — быть честным и открытым, а чтобы начать это делать, нужно перейти от согласования условий к сотрудничеству с заказчиком.
▍ Планирование проектов и Agile-компания
Одна из самых важных причин необходимости точных оценок сроков заключается в планировании ресурсов. Если для создания дизайна команде проектировщиков UX потребуется два месяца, нам нужно гарантировать, что команда разработчиков будет готова через два месяца принять результат и приступить к работе. Если для реализации этого дизайна команде разработчиков потребуется полгода, то нам нужно гарантировать, что команда QA будет готова к его тестированию через восемь месяцев. Если команда проектировщиков UX не уложится в дедлайн, то это вызовет проблемы на всех последующих этапах и повлияет на все зависящие от них отделы.
Это принцип Big Design Up-Front (BDUF). Мы делаем крупную ставку — в этом примере девять месяцев работы, которые для многих компаний могут означать разницу между успехом и банкротством — заявляя, что полностью поняли задачу, придумали правильное решение, и что в течение девяти месяцев этой работы не произойдёт никаких важных изменений. Каждое из этих допущений само по себе является ставкой, которую примут немногие профессиональные игроки, а всё вместе это (да ещё и с учётом размера ставок) превращается в чрезвычайно маловероятное событие.
Делать одну огромную рискованную ставку — не лучшая идея; мы должны делать одну за другой мелкие ставки. Не вкладывайте усилия в девять месяцев труда; вложитесь в две недели, а потом посмотрите, к чему вы пришли. Чтобы сделать это, вам с большой вероятностью придётся реорганизовать работу; команда проектировщиков UX не должна выполнять всю работу по исследованиям и проектированию, а затем перебрасывать её разработчикам, а разработчики не должны выполнять первичную разработку, а затем перекидывать её команде QA. Проектировщиков UX, разработчиков ПО и специалистов по QA нужно объединить в одну кросс-функциональную команду, а затем разделить работу на вертикальные срезы — части полной функциональности, которую команда сможет выполнить за выделенный объём времени, а затем посмотреть, что вы получите к его завершению.
Для выполнения своих задач кросс-функциональной команде не нужен долговременный план. В каждом новом цикле она готова взяться за любую наиболее важную работу, которую нужно выполнить следующей. Ей не нужны оценки сроков, им требуется только знать, что организация ждёт от них на следующем этапе. Участники команды должны коммуницировать с остальной частью организации и обеспечивать прозрачность выполняемых ими задач, чтобы было чётко понятно, на какой стадии всё находится. Организация должна использовать эту прозрачность, чтобы решать, какую следующую самую важную задачу необходимо выполнить; команда при этом будет знать, над чем начинать работать после начала следующего цикла работы. При изменениях на рынке вы можете пересмотреть в свете этих изменений следующую наиболее важную задачу. Каждый готовый вертикальный срез приносит с собой новые открытия и новое понимание, которое может изменить образ осознания задачи. Когда это произойдёт, вы снова можете пересмотреть в свете этих открытий следующую наиболее важную задачу. Именно благодаря возможности реагирования эта методика называется Agile («гибкая»).
Вы можете сказать, что всё это замечательно для маленьких команд, но не подойдёт для крупных организаций. Если у нас есть 50 дизайнеров, 100 разработчиков и 30 специалистов по QA, то их ведь не объединишь в одну кросс-функциональную команду из 180 людей? Это ни за что не сработает; поэтому их и разбивают на 30 команд, в каждой из которых 1 специалист по QA, 1-2 дизайнера и 1-4 разработчика. Если соединить стратегию вертикальных срезов с архитектурой вертикальных срезов и/или с микросервисами (если вам действительно нужны микросервисы), то каждая из этих 30 команд может взять свой срез одного и того же продукта и вам не придётся волноваться о коллизиях (которые лучше известны разработчикам по одному конкретному типу коллизий — конфликту слияний).
▍ Готов к выпуску
Даже несмотря на возможность более эффективной работы в мелких кросс-функциональных командах, регулярно выпускающих работающие вертикальные срезы окончательного продукта, это не избавляет нас от необходимости точных оценок сроков выпуска продукта. Выпуск продуктов — сложный процесс, зависящий от правильной координации. Маркетинг может быть масштабным многоступенчатым процессом, и обеспечение всего необходимого для рекламы выпуска продукта — серьёзная работа. Мы не можем просто придумать что-нибудь в последнюю минуту. Нам нужно назначить дату, чтобы планировать на её основе маркетинговые мероприятия.
Всё это правда; по крайней мере, для того, что называется жёстким запуском. Он отличается от мягкого запуска, который в последний десяток лет становится всё популярнее. При мягком запуске вы выпускаете что-то с гораздо меньшими фанфарами. Такая стратегия хорошо подходит для стартапов и minimum viable product (MVP), а MVP хорошо подходят для кросс-функциональных команд, регулярно выпускающих работающие вертикальные срезы. Так как в каждом цикле приоритет отдаётся следующему наиболее ценному срезу, мы просто определяем, какого количества срезов достаточно, чтобы продукт представлял ценность для реальных пользователей, и выпускаем его. На работу команды это практически никак не влияет; теперь она повышает ценность уже работающего продукта, но это исключительно бизнес-решение.
При мягком запуске можно рискнуть и выпустить продукт, который некоторым пользователям покажется недоделанным; именно поэтому в него не вкладываются большие маркетинговые ресурсы. Вы получаете отзывы от первых пользователей и используете их для выбора следующих наиболее ценных срезов. При использовании такой стратегии слишком долгое ожидание релиза более рискованно, чем слишком ранний релиз, потому что вы рискуете потратить время на срезы, которые пользователям неинтересны. Чем раньше вы что-то выпустите, тем раньше у вас появятся пользователи, которые скажут вам, чего они хотят. Мэтт Малленвег сформулировал это так:
Практическое использование — это кислород для идей. Вы никогда не можете предсказать, как аудитория отреагирует на то, что вы делаете, пока не выпустите это. Это означает, что каждая секунда работы над чем-то без публикации — смерть от недостатка кислорода реального мира.
При таком подходе вам не нужно пытаться предсказывать будущее. В процессе использования реального продукта реальными людьми он становится совершеннее, и вы постепенно вкладываете в него больше маркетинговых ресурсов. Нет никакого «большого запуска» и скоординированной маркетинговой атаки. Вы начинаете разработку и проводите кампании только после выпуска продукта и его готовности для рекламы широкой аудитории.
Тем не менее, нельзя отрицать то, что некоторые продукты действительно должны иметь жёсткий запуск; но как часто компании объявляют о дате выпуска долгожданного продукта, а потом снова и снова его откладывают? Мы не можем избавиться от того факта, что все оценки сроков — это ложь, что означает практически полную гарантию сдвига всех запланированных дат релизов вне зависимости от тяжести «кранчей», которые приходится терпеть сотрудникам (потому что, как и говорилось выше, эта стратегия просто ещё дальше отодвигает дату завершения).
Если вы хотите быть честными с самими собой и создавать планы, которые действительно работают, то стоит изучить удобство планирования и исполнения мягких запусков по сравнению с жёсткими. Если мы разрабатываем ПО итеративно, то при достижении точки, в которой стратегия мягкого запуска запустила бы MVP, мы можем запустить закрытую бету для избранной группы участников. Только достигнув в развитии продукта достаточно хороших отзывов бета-тестеров, вы можете начать планировать маркетинговую кампанию. На этом этапе у вас будет уже гораздо более глубокое понимание того, что необходимо для создания качественного конечного продукта, и того, сколько работы ещё для этого потребуется. Скорее всего, эти детали будут меняться между временем начала планирования и приближающейся датой выпуска, но поскольку вы уже разработали качественный базовый продукт, то у вас уже будет то, что можно выпустить. Можно начинать делать маркетинговые заявления, вызывающие восторг и предвкушение, параллельно участвуя в ярмарках, подкастах или телепередачах, покупая рекламные площади и проводя другие мероприятия для скоординированной кампании перед датой выпуска. Вместо того, чтобы решать броском монеты, будет ли у вас готовый продукт на момент релиза, вы точно будете знать, что у вас уже есть отличный продукт. Останется только вопрос, насколько лучше он станет на дату выпуска.
▍ Будьте честны с руководством
Наверно, вы уже догадались, что я думаю по поводу использования оценки сроков в отчётах высшему руководству и стейкхолдерам. Людям, принимающим решения, важно знать о текущей ситуации и её развитии, чтобы они могли принимать важные стратегические решения, но оценки сроков не дадут им этого, ведь все ваши оценки — это ложь. Они находятся в неведении о происходящем в реальности. Сложные диаграммы Ганта, проектные показатели, планы и оценки позволяют проекту, который уже несколько месяцев движется к катастрофе, выглядеть красиво; так происходит до самого последнего момента, когда приходит и проходит дедлайн. В этом и обнаруживается истинная ценность оценок: она заключается не в предоставляемой, а в скрываемой ими информации.
Agile-команды способны обеспечивать гораздо более высокую степень прозрачности того, чем они занимаются, что выполнили и что осталось выполнить. Это даёт ответственным за принятие решений людям максимум возможного понимания ситуации и позволяет им принимать решения, которые команда может начать реализовывать сразу в начале следующего рабочего цикла. Недостаток такого подхода в том, что принимающие решения люди будут точно знать, чем занимаются команды, что они выполнили и что ещё нужно выполнить… а это может вызывать ужас. Разработка ПО — рискованный процесс. И от этого никак не избавиться. Может выясниться, что цифровой продукт невозможно реализовать технически или он нежизнеспособен с коммерческой точки зрения. Хорошие менеджеры по продукту прогнозируют самые большие риски заранее (именно от этого зависит расстановка приоритетов для наиболее ценных следующих срезов — выявление наибольших рисков чрезвычайно полезно), и когда это происходит так, мы узнаём о них рано, а не поздно. Но даже если мы делаем всё правильно, в конечном итоге разработка ПО — это исследование. Даже в самом конце есть вероятность того, что мы найдём нечто, превращающее все наши усилия в пустую трату огромного количества времени и денег.
Из-за прозрачности мы никак не сможем спрятаться от этой ужасающей правды. Все мы люди, поэтому понимаем, почему ответственные за принятия решений склонны к использованию систем, скрывающих все эти тревоги за высокой непроницаемой стеной планирования проектов. В этом случае риск по-прежнему присутствует, но нам необязательно его видеть. Если всё удастся, но вам никогда не придётся с ним сталкиваться. У нас проходит большой успешный запуск и мы все получаем премии за отличную работу. Но если это не срабатывает, а такое, согласно приведённому выше опросу, случается в 48% случаев, то происходит взрыв рисков. Акции рушатся. Сотрудников увольняют. Мы требуем сообщить нам, кто виновен во всём этом, но если быть действительно честными с собой, то ответ будет очевиден: ошибки сотрудников не идут ни в какое сравнение с неизбежным результатом сокрытия всех этих рисков.
Agile позволяет нам перестать врать начальнику и обеспечивает ему прозрачность, показывающую, что происходит на самом деле, но в таком случае им приходится становиться не боссами, а лидерами. Борьба с неопределённостью пугает, ведь необходимо признать, что в этом бизнесе присутствует риск. Можно спрятать его в шкаф, или замести под ковёр, или даже воспользоваться довольно эффективными способами его минимизации (если осмелитесь признать его), но устранить риск полностью невозможно. Это неотделимая часть работы. Если вы сможете принять это и верите в своих людей, то они смогут быть честными с вами и вместе вы сможете найти способы одолевать, минимизировать и регулировать эти риски. Если вы не можете, то вам придётся попросить своих сотрудников продолжать врать вам, а потом удивляться, почему так много проектов неизбежно заканчиваются провалом, несмотря на то, насколько прилежно вы обновляете свои диаграммы Ганта.
▍ Главный критерий измерения прогресса
Если вы выберете в качестве критерия «достаточного качества» чего-то косвенный показатель, то это всеми возможными способами даст вам понять, что косвенный показатель — не то, что вас интересует на самом деле. Давным-давно платформы соцсетей решили, что хорошим косвенным показателем удовлетворённости пользователей является длительность нахождения на сайте, и начали оптимизировать эту метрику. В результате они создали цифровой аналог опиатов и игровых автоматов. Кроме того, я уверен, что многие из вас смогут вспомнить истории разных организаций, которые выполняли огромные суммы сторипоинтов, или Scrum-команд, которые стабильно увеличивали velocity с каждым спринтом, но создавали едва работающее ПО.
Седьмой принцип Agile-манифеста гласит:
Работающий продукт — основной показатель прогресса.
Не сторипоинты, не velocity, не оценки сроков: только работающее ПО. Если вы сделаете их показателем своего прогресса, то закон Гудхарта скажет вам, чего ждать дальше: вы будете создавать кучу сторипоинтов и высокую velocity, но, скорее всего, не очень работоспособное ПО. Если мы хотим других результатов, то нам нужно сосредоточиться на том, что мы действительно хотим.
Распространение тега #NoEstimates в Twitter началось с того, что своими историями делились люди, недавно завершившие крупные сложные проекты без каких-либо оценок сроков. Прямо сейчас люди поступают так даже в больших, сложных проектах наподобие вашего. Вместо того, чтобы писать научно-фантастические рассказы о том, каким может быть будущее, мы можем сформировать кросс-функциональные команды, реализующие вертикальные срезы работающего ПО, чтобы мы могли измерять свой прогресс не в сторипоинтах, velocity или какой-то другой лжи, а в настоящем работающем ПО, которое существует и запускается.
Если после всего вышесказанного вы всё равно уверены, что в некоторых ситуациях оценки сроков нужны, то я предложу следующее: сторипоинты и velocity активно используются в Scrum-командах. Не менее одного раза в спринт команда собирается, чтобы «причесать» бэклог, и в это время она рассматривает пользовательские истории из своего бэклога и присваивает каждой какое-то количество сторипоинтов. Чаще всего используются числа из последовательности Фибоначчи. Это позволяет scrum-мастеру или владельцу продукта вычислить velocity (среднее количество сторипоинтов, которые команда завершила за последние несколько спринтов). Используя это среднее значение, они могут спрогнозировать, что при сохранении командой той же скорости она сможет завершить за следующий спринт такое-то количество пользовательских историй, что можно превратить в прогноз того, сколько времени понадобится на разбор бэклога.
В своей книге #NoEstimates Васко Дуарте говорит, что если бы мы отказались от чисел Фибоначчи (то есть заменили 1, 2, 3, 5 и 8 на 1, 2, 3, 4 и 5), то получили почти такие же прогнозы. Более того, если мы полностью откажемся от этих оценок (по сути, если каждая пользовательская история будет стоить 1 сторипоинт), то мы всё равно получим почти аналогичные прогнозы. Это значит, что мы или можем один час в неделю регулярно заниматься разбором бэклога, анализировать каждую пользовательскую историю и использовать покер планирования для подбора их подходящего размера, или можем просто подсчитать количество историй в бэклоге. Прогнозы в любом из случаев будут одинаково полезны (хотя один из них требует гораздо меньше времени и усилий).
В руководстве по Scrum приводятся конкретные ценности, для реализации которых нужен этот процесс. Одна из них — это «смелость»; эта ценность была позаимствована у его предшественника, экстремального программирования. Возникает вопрос: зачем Scrum требует «смелости»? По моему опыту, Scrum-команды чаще всего терпят неудачи из-за отсутствия смелости, чем по какой-то иной причине. Обычно именно нехватка смелости заставляет организации создавать карго-культы вместо «гибкости» и именно нехватка смелости заставляет нас прятаться за оценками сроков, вместо того, чтобы взглянуть в глаза неоспоримому факту: разработка ПО — это риск. Когда мы слишком боимся принять это, такие риски накапливаются и растут в тех местах, где мы их прячем. Они разрушают наши проекты, наши компании, наши карьеры и даже наши жизни. Если мы признаем их, то сможем минимизировать. Мы сможем выявлять их до того, как поставим всё на карту в ожидании результата. Мы сможем их устранять, обходить, справляться с ними и управлять ими. Но только если сначала наберёмся смелости взглянуть им в глаза и честно говорить о них друг с другом и с собой.
Помоги спутнику бороться с космическим мусором в нашей новой игре! ????
Комментарии (52)
fakedtf
17.01.2024 13:09-24Разработка ПО — это исследование
Ну если вы бросили универ на 2 курсе и вообще пошли учиться чтоб откасить от армии и переехать в город побольше - да. А для всех остальных это просто "набрать код слепой печатью". Как все живут нормально, но только в стране с самым лучшим в мире коммунистическим образованием и заряжателями бутылок у телевизора, опять всё какие-то исследования.
Скрам это калл.
ovsds
17.01.2024 13:09+32...стране с самым лучшим в мире коммунистическим образованием и заряжателями бутылок у телевизора...
/sarcasm_mode on
Речь, видимо, про США, не знал, что там коммунизм.
/sarcasm_mode off
FYI, автор оригинала - Jason Godesky, закончил University of Pittsburgh.
beduin01
17.01.2024 13:09+19А для всех остальных это просто "набрать код слепой печатью".
Я так понимаю, что вы hello-world'ы пишете?
modelair
17.01.2024 13:09сразу мне вспомнилась притча о мухе и шмеле. очевидно, комментатор — муха, да еще и без одного крыла, к тому же.
Emulyator
17.01.2024 13:09+8Ну почему же сразу все оценки - ложь? Оценка сроков "от нуля до бесконечности" звучит довольно правдоподобно. Я бы еще добавил, что иногда проблема в том, что вместо того чтобы взять решение задачи, которое мы знаем, мы создаем другое решение, потому что это интереснее, и якобы правильнее (я вот регулярно так делаю). )
akakoychenko
17.01.2024 13:09+20Неплохие мысли поначалу, но потом в такой догматизм и невежество скатывается, что читать противно. Не удивлюсь, если автор оригинала из тех, кто за серьёзные килобаксы помогает серьёзным дядям "внедрить скрам в сжатые сраки(с)"
Но, вцелом, если брать адекватное и технически подкованное начальство, то оценки нужны не для планирования ресурса, а для приоритизации. Руководителю ведь, как правило, нах не надо выполнить таски 123, 456 и 789 в следующую неделю (за исключением багов на проде или безальтернативных внешних обстоятельств). Ему надо поднять вовлеченность, или уменьшить отток, или заинтересовать новых клиентов и так далее. Ему надо пройти из точки А в точку Б в бизнесе, и, как правило, есть тысячи способов сделать это, а задачи в беклоге это лишь одно из предположений, как. И, поэтому, получив оценки на варианты достижения точки Б от разработчиков, руководитель может оценить, а действительно ли ему надо именно эта таска выполнена, или подойдёт альтернатива, которая приведет бизнес в Б', который не сильно хуже Б, но требует в 3 раза меньше ресурса
kpmy
17.01.2024 13:09+5Ещё оценки нужны для манипуляций в стиле "вы же мне обещали за три недели выкатить фичу на прод... поэтому в пятницу вам вместо пиццы устроим овертайм до победного деплоя"
ilnoor
17.01.2024 13:09+1Если надо пройти из точки А в точку Б оптимальным маршрутом, то задача и должна так ставиться. Выбор способа из тысяч - тоже часть решения задачи. Зависит наверно от задачи, но я думаю что вовлечение менеджмента в процесс выбора - это микроменеджмент
akakoychenko
17.01.2024 13:09+1Оно то звучит красиво на практике, но, объективно, есть решения уровня программиста, а есть решения уровня продакта/руководителя. К примеру, если в системе есть race condition, и точкой Б есть его отсутствие, то, да, как его избежать, - пусть решают программисты. Но вот, выбирать между тем: исключить его полностью, потратив 2 недели, увеличив клауд кост на $1000/мес за счет усложнения архитектуры и добавив вероятности новых багов, или уменьшить его вероятность в 10000 раз, потратив день на хитрожопый патч, - это уже решение не программиста, увы. Для решения этой задачи надо обладать тем контекстом, который программисту просто невозможно знать (ибо фокус и объем внимания ограничен)
NewMan_by
17.01.2024 13:09+6Не каждое программирование это исследование, конечно, если вы создаете что-то принципиально новое, как пример с тем же лекарством от рака, то да. Но в современных реалиях 80% и более - программирование это написание похожего кода.
В любой работе, где есть отхождение от рутины, будет элемент исследования, а все остальное рутина.
Ничего нового статья не привносит, кроме попытки из программистов сделать особых людей с особыми правами.
Arqwer
17.01.2024 13:09+6Так рутины в программировании почти нет. Пусть надо сделать X. Если X никто ранее не делал, то это - исследование, сколько займет времени - неизвестно. Если надо сделать X второй раз - то выполняется копипаст. Опыта копипаста X нет, понятно только то, что он будет выполнен быстрее, чем в первый раз. Если надо сделать X в третий раз - то выполняется рефакторинг и автоматизация выполнения X. Сколько времени на это нужно потратить - тоже неизвестно, потому что опять, задача "автоматизировать X" решается впервые. В четвёртый раз делать X никто не будет, потому что уже налажена автоматизация, и оно делается само.
dmserebr
17.01.2024 13:09+2Если надо сделать X в третий раз - то выполняется рефакторинг и автоматизация выполнения X
Если стоимость рефакторинга / автоматизации на 1-2 порядка превышает стоимость выполнения X, то автоматизация просто может оказаться нецелесообразной на текущем этапе (например, без понимания востребованности продукта на рынке). Также бывает, что для автоматизации нужны какие-то дополнительные ресурсы / технологии, которых сейчас нет.
Так что в теории все красиво, но на практике рутинные задачи встречаются довольно часто.
Gradiens
17.01.2024 13:09+12Полностью солидарен, если я - исполнитель.
Категорически не согласен, если я - заказчик. Заказчику нужно знать ответы на вопросы "сколько" и "когда".
При этом не стоит считать, что софт - это прямо сложно и непредсказуемо, а, например, строительство - просто и прогнозируемо. Наивно недооценивать сложность реального мира.
Недавний пример: нанял рабочих выкопать канаву на даче. Это даже проще, чем класть кирпичи, не так ли? По логике, каждый следующий метр канавы - он такой же, как предыдущий? Так-то оно так, но ровно до того момента, как рабочие уткнулись в закопанную груду кирпичей.
Не надо считать разработку - чем-то особенным. Другие области ничем не легче. А зачастую - сложнее и менее толерантны к изменениям. Если вы строите 10-и этажный дом, вы не можете посередине строительства передумать и построить 20 этажей. Каким бы гением не был ваш архитектор. А если вы строите софт, и у вас толковый архитектор, то добавить в 2 раза больше функционала, или в 2 раза увеличить нагрузку на систему - можете. Это будет стоить времени и денег, но - можете.
Возвращаясь к оценке. Если считать оценку не числом, превращающимся в обязательство по факту его озвучивания, а функцией распределения вероятности - то она вполне имеет право на жизнь.
И если вы хотите прозрачности, то накопите статистики, расскажите бизнесу азы "тервера", управляйте рисками и работайте.
Ваш бизнес не хочет слушать и требует одно число? Сочувствую. У меня такое регулярно. Качайте ораторское мастерство. Закладывайтесь со сроками по 90-му или 95-му персентилю (если хватит наглости) Или меняйте бизнес. Ну или фрустрируйте и пишите статьи о невозможности оценок.
olegchir
17.01.2024 13:09+4Дополнительные +10 этажей - наверное, нельзя. Но есть куча примеров, когда к существующим домам достраивали этажи в количестве 1-2-3 штуки, и даже делали на крыше какой-нибудь бассейн (который куда тяжелее обычного этажа).
poulch
17.01.2024 13:09+1можно все. снес и построил с 0. в начале 90х когда только начинал программировать было несколько раз что готовый на 90% проект полностью переписывал с 0. причем тогда у меня еще не было своего компа дома и код turbo pascal + turbo vision я писал на тетрадных листах и быстро вбивал на рабочем компе... с возрастом лень тренирует навык построения более грамотных фундаментов и сносить в 0 уже не надо и лень :)
saboteur_kiev
17.01.2024 13:09+1Если вы строите 10-и этажный дом, вы не можете посередине строительства передумать и построить 20 этажей. Каким бы гением не был ваш архитектор.
То есть?
Все возможно. Но это может стоить разную сумму, из которой основная часть - это фундамент. Если он может выдержать нужный вес, то укрепить текущую часть и достроить - дело техники. У меня есть даже живой пример как комплекс 12-24-12 этажей переделали в 24/24/24/24 уже тогда, когда первые 12 были построены.
Portnov
17.01.2024 13:09+1ну собственно в данном случае аналогия практически буквальная. "фундамент" в разработке ПО это то что называется архитектурой: базовые решения об устройстве ПО, принимаемые в самом начале проекта. Он обеспечивает некоторую степень прочности, благодаря которой можно "достраивать этажи". Или нельзя.
piton_nsk
17.01.2024 13:09+2У меня есть даже живой пример как комплекс 12-24-12 этажей переделали в 24/24/24/24 уже тогда, когда первые 12 были построены.
Есть подозрение что такая перестройка была запланирована заранее. Так иногда делают чтобы обойти нормы по застройке.
saboteur_kiev
17.01.2024 13:09Нет, однозначно не было. Но грунт позволил. Фундамент укрепили уже рядом с домом, но построенные секции уже не разбирали, только провели работы по укреплению.
Стоит уже 7-й год.
Xobotun
17.01.2024 13:09Да, мне во всяких корпоративных жирах не хватает дать оценку в виде нормального распределения "1 день ± 4 часа" или "1-2 дня".
Можно, конечно, по верхней границе оценивать, но это чревато непониманиями с другими людьми, кмк.
erpacademy
17.01.2024 13:09+1К разработке ПО можно относиться как к искусству, ремеслу, инженерии. Если речь о коммерческой разработке приложений, то предпочтительнее третий вариант (использование паттернов ООП, высокоуровневых паттернов, спецов, набивших руку на подобных задачах). Этап исследования в этом случае может быть в проекте; но как этап предваряющий производство (кодинг). Методология может быть любой, главное - использовать объективные/измеряемые/проверяемые данные/показатели, а не частные мнения/оценочные суждения. По комментариям выше, вижу, что смешиваются понятие "программирование" и "проектирование". Разработка (development, "развитие") - это и первое, и второе (сначала проектирование, конечно). В общем, в названии статьи пропущены слова "на практике" между "... ПО" и "- ложь".
thesame
17.01.2024 13:09+1В каком-то смысле эта статья - эталон. Эталон непонимания того, что есть профессия программиста.
Начнем с середины: "Каждый кирпич обычно очень похож на любой другой, по крайней мере, в том, что важно при строительстве стены. Количество времени, необходимого для укладки всех кирпичей, в общем случае довольно близко ко времени укладки одного кирпича, умноженному на количество кирпичей" - почти любой программист использует в своей работе библиотеки. Библиотеки - это те же самые кирпичи, которые надо сложить вместе и соединить кодом, чтобы получить стену. Если программист не может сложить из имеющихся "кирпичей" стену - это не программист. Равно как каменщик, который с точностью до килограммов не может назвать объем раствора, чтобы построить стену из имеющихся кирпичей - не каменщик.
Хорошо, идем дальше - "Почти всё время разработки тратится на новые задачи, ответов на которые мы не знаем. Часто они новы ужасно скучным образом, например, «как нам сохранять эту модель данных с этими конкретными полями в эту конкретную базу данных?» Но именно из-за них эта ситуация отличается от всех остальных (или, по крайней мере, от тех, которые мы смогли найти) и именно это занимает всё наше время" - нам дали десять (двадцать, сто) камней, чтобы сложить стену, но мы не знаем, как это делать - и это нам говорится открытым текстом и преподносится, как откровение свыше. "Разработка ПО — это исследование" - ребята, вас обмвнули: исследованием является только создание нового "кирпича" (нового алгоритма). Все остальное является ремеслом. "как нам сохранять эту модель данных с этими конкретными полями в эту конкретную базу данных?" - лично я гнал бы за такой вопрос даже джуна. С объяснением "учи кирпичи!"
А потом идет кромешный ужас под названием agile/scrum. Если при проектировании системы были допущены огрехи, то их иногда можно исправить. А иногда проще переписать с нуля. И никакими еже...ными митингами ничего не сделать.
Короче: работа программиста состоит в том, чтобы реализовать заданный в ТЗ алгоритм. Разработкой алгоритмов занимаются, как правило, другие люди. Срыв дедлайна - ЧП.
Abobcum
17.01.2024 13:09+5Короче: работа программиста состоит в том, чтобы реализовать заданный в ТЗ алгоритм. Разработкой алгоритмов занимаются, как правило, другие люди. Срыв дедлайна - ЧП.
А теперь представьте, что ТЗ нет, алгоритмов тоже нет, профильные специалисты также отсутствуют. Есть только абстрактная задача сверху.
akakoychenko
17.01.2024 13:09Есть и такое. Но, это вообще не о программировании и не о разработке ПО. Как правило, должность человека, решающего столь абстрактные задачи, называется CEO, COO, General Manager, или, хотя-бы, Head of business unit, и подразумевает, что человек хотя-бы на очень базовом уровне понимает оперирование, маркетинг, финансовое планирование, управление персоналом, ИТ одновременно. Ибо помимо написания кода есть масса способов решить абстрактную задачу (например, приобрести доступ к сервису, исполняющему код у того, кто его уже написал и почистил от багов, или, нанять и обучить 10 студентов, которые все отлично сделают в Excel).
Если уже дошло до привлечения к процессу программиста, и было принято решение, что абстрактная задача решается именно разработкой ПО, значит, как правило, таки да, ждут именно реализации алгоритма, иногда, к слову, описанного не императивно, а декларативно (составь маршрут для курьера, чтобы он развез все посылки, потратив минимум бензина). И, таки да, если мы не говорим о компаниях, которые изобретают новые кирпичи (как open ai), то, и ожидается при этом, что программист именно и возьмёт готовые кирпичи и соединит их предсказуемым способом, а, если таких кирпичей на рынке нет, то тот час же сообщит об этом, и уточнит, действительно ли ему готовы платить за потуги для изобретения нового кирпича за неопределенное время с неопределенным результатом, или же, лучше подумать над более конкретным заданием
Spyman
17.01.2024 13:09+1Пример - к вам приходят с задачай - реализовать какую то функцию который на данной момент в программе нет.
Вариант 1 - вы знаете наизусть все 1.5 миллиона строк кода приложения и их текущее состояние, ваши знания о механизмах и библиотеках исчерпывающи и абсолютны -
В таком случае вы за вычисляемое время легко дадите оценку задаче, и скорее всего в неё даже попадёте, если не будете зависит от сторонних сервисов.
Вариант 2 - вы не знаете весь код наизусть. - тогда вы можете потребовать время на оценку - неопределённое время, потому что вам нужно пересмотреть все затрагиваемые места, убедиться что там "всё стандартно" или "что-то не стандартно", перечитать документацию по каким то библиотечным местам, понять какой код куда и зачем нужно вписать. В этот момент вы сможете дать довольно точную оценку, правда фактически зачастую может получиться что вы сначала потратили 2 дня на оценку а потом оценили в 15 минут, и точно попали. Если же время на оценку зафиксировать (например 2 часа), то точность попадания в оценку будет падать пропорционально времени которое непотраченному на исследование.
А если к этому примешиваются сторонние сервисы - а обычно компонентов штуки три - фронтенд, бэкенд, биллинг, то в точность оценки добавляется еще и их влияние, которые вы не можете учесть.Конечно, бывают и приложения, где один и тот-же человек делает одну и ту-же задачу достаточно часто - чтобы для него всё было очень предсказуемо. Например если вы занимаетесь исключительной вёрсткой страниц ошибок, которые немного отличаются дизайном, положением текста об ошибке, и количеством возможных кнопок. Или исключительно добавлением новых форматов товаров, которые отличаются только набором полей но для каждой 2 маппера и 1 вариант отображения в фрейме фиксированного размера. В таких случаях оценки отлично работают и довольно точно отражают истину - но проекты где такое происходит редки, да еще и зачастую - бизнес логика их не содержит необхоидмости в этих дейсвтиях - они являются следствием архитектурной ошибки, которая привела к необходимости выполнять одну и ту-же работу многократно вместо переиспользования.
mianoki
17.01.2024 13:09-1Горячо пожимаю вам руку, коллега!
Полностью согласен.
В мире уже давно определили две совершенно разные деятельности:
1) Программирование - это специальность (computer sciences, programming). Программист пишет - да хоть карандашём словами на бумаге - математику и алгоритм.
2) А вот наиболее распространённый "зверь" - это Кодер (coding), и это НЕ специалист, а рабочий.
Первый - примерно как архитектор/проектировщик, а второй - каменьщик/монтажник ;)
Увы, очень часто происходит грубое смешивание этих двух деятельностей со всеми вытекающими. А уж HR'ы так вообще как будто применяют random для описания вакансий)
nronnie
17.01.2024 13:09+3Короче: работа программиста состоит в том, чтобы реализовать заданный в ТЗ алгоритм
Это не программист, а
машинисткакодерРазработкой алгоритмов занимаются, как правило, другие люди.
А вот это уже программист.
dimaaannn
17.01.2024 13:09+4Разработкой алгоритмов занимаются, как правило, другие люди
В стране волшебных пони, у каждой специализированной задачи есть отдельный человек.
Аналитики пишут ТЗ, архитекторы говорят как его реализовать, девопсы настраивают рабочие процессы, менеджеры разбивают ТЗ на план, а программист просто берёт следующую задачу из списка, где всё подробно расписано.
Вот только в реальности всё это может делать один человек. Потому что нету ни девопса, ни аналитика, ни архитектора. Есть только менеджер, который договорился с клиентом, легаси код который как то работает, и сроки выполнения.
funca
17.01.2024 13:09нам дали десять (двадцать, сто) камней, чтобы сложить стену, но мы не знаем, как это делать... "учи кирпичи!"
Между двадцатью и ста есть разница.
Ради интереса, попробуйте оценить: сколько времени у вас займет собрать пазл из соответствующего количества плиток? Здесь ведь даже учить ничего не надо - просто собрать. А потом реально собрать и порефлексировать над результатами.
Чтобы ещё больше приблизить игру к реальности, попробуйте предварительно смешать плитки из нескольких однотипных наборов. Просто в конце покажете несколько картинок, сложенных рядом.
Половину из них раздайте детям - с условием, чтобы они все вернули ровно через час. Оставшейся половины вам ведь точно должно хватить, чтобы не сидеть без дела всё это время?
Да, кто-то из детей потом может опоздать. Кто-то в процессе потеряетет какие-то детали, но чтобы не огорчать отца, заменит на примерно похожие. Поэтому разницы сразу вы не заметите. Но в конце результат у вас все равно должен быть как на макете.
Теперь снова прикиньте оценку. А может вам хватит простого коэффициента?)
zodchiy
17.01.2024 13:09+1Ещё труднее объяснить, что проект всё, мертв, хватит пинать мертвую лошадь. Некоторые менеджеры просто в это не могут поверить.
Robastik
17.01.2024 13:09Есть какие-то объективные симптомы смерти прокта?
zodchiy
17.01.2024 13:09+1Самый верный признак технологической смерти проекта, когда разработчики начинают говорить вслух о том, что надо не просто рефакторить часть кода, а что-то менять в архитектуре, а на вопрос о техдолге у тимлида дергается глаз.
zodchiy
17.01.2024 13:09+1Но это субъективщина. Если объективно, то когда внедрение функционала, который раньше добавлялся в обычном порядке, нужен существенный рефакторинг архитектуры и после этого добавление нового функционала опять вернется в обычный режим.
bigandre
17.01.2024 13:09+2Думаю в статье никак не рассмотрен момент, который крайне сильно влияет на сроки - а именно "мотивация". В нашей стране принято мотивировать некоторой "грамотой", которая нафиг ни кому не нужна. А если в качестве мотивации будет, к примеру, автомобиль, да причем не одному, а каждому - наверняка будет и результат. К сожалению любое руководство предпочитает не тратить лишних денег "на холопов", а мотивировать только путем "наказания" - что естественно обрекает практически любой проект на провал. В лучшем случае, в случае успеха раздают "подарки" - какие-нить чехлы к телефонам, коврики к мышкам - в общем бесполезное фуфло
IntActment
17.01.2024 13:09+4Я работаю в Японии в бодишопе, и хотел бы рассказать, как на моем примере обстоят дела с разработкой в Японии.
Я как-то однажды об этом уже писал: в Японии разработка ПО, по сути, относится к сфере услуг, со всеми вытекающими. Помните знаменитые фразы "покупатель всегда прав" и прочее? Вот тут это возведено в абсолют, из-за азиатского менталитета "угодить
покупателюзаказчику любой ценой". И сроков это тоже касается. Твой менеджер спрашивает у тебя сроки, но они всегда упираются в "сделаем максимум за месяц", потому что заказчик имеет свое расписание, а дополнительных людей на проект выделять никто не будет. Также стоит держать в голове, что сторонними библиотеками почти наверняка пользоваться нельзя, ибо заказчик скорее всего не захочет возиться с лицензиями - так что никаких "кирпичиков", как пишут некоторые. За множество однотипных проектов собрал свои наработки в библиотеку? Тебе не разрешат ее использовать в следующем проекте, потому что это лишняя dll, хотя никаких причин для этого нет - разве что "заказчик может не захотеть", о чем заказчика менеджер на самом деле спрашивать не станет. Заказчик захотел 3д в приложении? Пиши на opengl с нуля. Ну как с нуля, приходится чуть ли не умолять менеджера, чтобы разрешил использовать glfw и glew (и то, представьте, когда вы сидите на митинге с заказчиком и менеджер заискивающим тоном сначала неловко спрашивает об этих 2 библиотеках, и тут же оговаривается, что в принципе можно обойтись и без любой из них, если заказчику "неуютно"). Когда тебя спрашивают почему ты хочешь их использовать - отвечаешь резонное "потому что имею опыт работы, в 3д-области это важно" - и тебе менеджер делает замечание, что так заказчику говорить нельзя, мол, я навязываю тем свой выбор... В общем, нельзя беспокоить заказчика, а точнее - как либо потенциально обременять. Чтобы вы понимали специфику - в Японии работники сферы услуг вечно кланяются и благодарят покупателей-посетителей за любой чих, и даже извиняются за то, что просто оказались на пути вашего взгляда до нужной вам полки с товаром. И вот подобное поведение проецируется и на разработку. Даже если это поведение вредит результату. Еще раз уточню - я не говорю за всех, но когда на корпоративах спрашиваешь у местного начальства, они утверждают, мол, это нормальный подход в японских компаниях.
Yuri_nedre
17.01.2024 13:09+1Любая оценка, даже с большой погрешностью, лучше, чем ее отсутствие.
Не попадание в оценки - это нормально.
Рефлексировать и устранять промахи в оценках - это необходимость.
Нельзя строить долгосрочные планы без каких либо оценок.
Ни один нормальный проект не будут начинать, не попытавшись оценить сроки.
А вообще, это звучит, как, "еще 100500 отмазок, почему мы не хотим оценивать сроки".
Автор привел кучу причин, почему он этого делать не хочет и ни одной, почему это важно делать. Отмазка джуна, к которому пристает ПМ.
greysoft
17.01.2024 13:09Исследование это когда: а если я напишу так, что получится? А если я напишу по-другому, что получится? а если вообще ничего не написать, что получится? Разработка и исследование это разные вещи.
kasiopei
17.01.2024 13:09+2Когда задача типовая(сайт визитка), то какие-то сроки можно называть. Когда что-то непредсказуемое, то пытаться давать прогноз, но договор за время работы, а не за проект. Фиксированное время разработки это фиксированная стоимость и аффективные менеджеры будут стараться сдать в срок(а лучше на пару месяцев раньше чтоб премию получить) Мне еще не удалось угадать время. Заставляю себя умножать время на 3, но всеравно не хватает.
pavelsc
17.01.2024 13:09+3Для большинства разработчиков ПО оценки сроков — это ложь
Тебя напрягает, что ты можешь нечаянно соврать о сроках, меня напрягает, что я могу случайно сказать правду. Мы с тобой на разных уровнях.
Я уверен, что большинству из вас приходилось перерабатывать и трудиться по ночам, чтобы уложиться в дедлайн
Ещё чего. Просто за день-два до конца спринта говорю, что не успеваю, задача переоценивается, при необходимости дробится, и вставляется в следующий спринт. В 17:59 крышка ноутбука хлопает вне зависимости от статуса.
Акции рушатся. Сотрудников увольняют.
Обожемой, как хорошо что что я не покупал акции своей компании. Ну уволят и уволят, финансовая грамотность как раз о том, чтоб увольнение пугало меньше, чем пустой рулон туалетной бумаги дома, а не о том как рефинансировать кредит на 20 лет ))
Вы можете услышать раздражённое «Не понимаю, почему нужно так много времени»
Главное не вступать в вялотекущее противостояние, увидел раздражение - не сдавай позиции, пытаясь сгладить конфликт и убедить логикой. Вы проиграете. Это его работа убеждать людей подписаться на невыгодных условиях, а заполучив устный контракт придавить вас взятыми обязательствами.
Тому, кто так говорит предлагаешь сесть и сделать за меньшее время, пока ты его менеджерскими задачами займешься)) Почти любого мелкого начальника довольно сильно выбесит даже такой безобидный формат. Сразу же всплывёт его некомпетентность в продукте и посредственные софт скиллы. Есть какой-то шанс, что уволят именно тебя, но так ли тебе надо место с овертаймами и некомпетентными менеджерами?
vladonchik96
17.01.2024 13:09Что могу сказать по поводу статьи. Автор явно забывает что помимо дизайнеров, разработчиков и тестировщиков как правило команда состоит ещё Менеджера, Аналитика(ов) (Бизнес и системный). Чтобы начать прогнозирование, Менеджер изначально топает к аналитику и да, на раннем этапе сроки могут быть неточные, но по мере аналитики вполне с высокой точностью можно определить сколько потребуется разработке и дизайну на внедрение соответствующих фичей.
Хотел ещё написать, что итерационное планирование на тех же груммингах задач позволит достаточно близко попасть точно в глобальных сроках. В конце правда вспоминается про scrum подход.
Вообще главная задача менеджеру это подобрать адекватный множитель к срокам (не забываем, что те же сторипоинты вполне можно перевести в сроки по средней производительности команды)
Что по итогу, некоторые мысли в статье в целом верные, но излишнее утрирование и догматизация ведут явно куда-то не туда
GrP
17.01.2024 13:09Вообще главная задача менеджеру это подобрать адекватный множитель к срокам (не забываем, что те же сторипоинты вполне можно перевести в сроки по средней производительности команды)
Ещё бы неплохо помнить, что это не множитель, а, скорее, нелинейная функция. Что-то вроде "таск на 1сп = 4часа", "таск на 3сп=16часов", "таск на 8сп=80часов", "таск на 13сп= задача неясна, декомпозируй и оценивай заново, а то за все разумные сроки вылетишь".
DevNul
17.01.2024 13:09+2Имею скромное мнение о сроках.
Часто эти сроки требуют ушлые менеджеры, которые смутно понимают специфику работы вообще, код и в глаза не видели, не то, что писали - им просто надо отчитаться.
Им кажется, что так они будут "меньше корову кормить и больше ее доить", что программисты ленивые и будут тогда работать. Часто это люди сами весьма необязательные и ненадежные - судят по себе.
На практике, оказывается, что сроков вообще никаких не нужно было, а программисты, как люди люди ответственные при этом сидят на нервах, потому что "ну я же обещал".
Вместо того, чтобы потратить лишние 5 минут на спокойное чтение документации - начинают гнаться, чтобы успеть.
А потом эта срочная "фича" лежит еще 2-3 недели просто так. Вопрос - с чего бы вдруг, надо же было срочно?
Раньше работы была такая, что это было часто - у меня это вызывало стойкое желание встать и послать всех. Предложить уважаемым менеджерам самим сесть и сделать.
Если в компании такие менеджеры, которые не могут осознать даже, что сделать табуретку и разработать новый самолет - это разные вещи, то надо просто напрямую об этом сказать главному руководителю.
Если руководитель адекватный, он объяснит менеджерам, если нет - просто уйти.
Лучше так, чем постоянный нервяк 24/7, потому что надо сделать "внезапно".
Я через это проходил и как программист с в самом начале, и как руководитель уже большой группы людей - больше ни за что не соглашусь на подобное
xtov0
17.01.2024 13:09+1Известно, что Альберт Эйнштейн любил на досуге колоть дрова, посвящая этому делу не один час.Когда его спросили о причинах любви к такому занятию, он ответил, положив топор рядом с очередным поленом и утирая пот со лба:- В отличие от всех остальных моих занятий, эта деятельность позволяет мне сразу увидеть результат.
funca
17.01.2024 13:09Я называю это наркомания - стремление получить удовлетворение как можно быстрее. На это подсаживаешься, это вызывает привыкание, отсутствие быстрых результатов приводит к ломке и даже - выгоранию. В таком состоянии люди готовы буквально на всё, чтобы получить очередную дозу своего удовольствия сию секунду, даже на преступление.
Когда менеджеры требуют оценку немедленно, программисты коммитят код без тестов, чтобы закрыть задачу, а тестировщики красят в зелёный неглядя - вот это оно.
funca
17.01.2024 13:09Для тех, кто у вас спрашивает оценки, а потом назначат их же вам как дедлайны - наверняка в аду приготовлен отдельный котёл.
Вообще задачи условно делятся на две категории. 1. Которые понятно как делать. 2. Которые - не понятно.
Задачи первого рода есть всегда и вы можете дать для них оценку с большой долей достоверности. Так сделайте это.
Если столкнулись с задачей второго рода, то положите в спринт спайк с задачей на исследование, и целью - родить план для дальнейших действий, которые уже сможете оценить. Установите на нее психологически и финансово комфортный лимит по времени сверху. Все у вас снова есть вполне правдоподобная оценка.
В итоге все задуманное либо будет оценено и выполнено. Либо вы от чего-то откажетесь, если сочтёте нерешаемым. Но у вас для этого уже будут все основания.
kbi
17.01.2024 13:09Боже ж ты мой. обычно проговорив с программистами сроки и умножив это всё ровно на два ты практически всегда укладываешься в запланированные тобою сроки разработки.
leok
Ложь по определению требует, чтобы сторона, которая ее говорит, знала, что она говорит неправду.
rsashka
Да ладно, может же быть честное "заблуждение" :-)
SergioT4
Обычно это называют SWAG - scientific wild-ass guess. Название как бы подчёркивает точность прогноза.