Как избегать фатальных ошибок в разработке

09.02.2025   /   Практика  
Метки:

При принятии решений нужно стараться избегать фатальных ошибок. Как говорят трейдеры: «Можно заработать много раз по 100%, но потерять 100% можно только один раз».

  1. Как выглядит фатальная ошибка в разработке программного продукта — команда берется за очень классный, но очень большой продукт или новый функционал в текущем продукте. Через год закопанных усилий и денег выясняется:
    Так и не смогли реализовать задуманное, а бюджет или терпение заказчика кончилось.
    Сделали, но оказалось никому не нужно, либо нужно, но требуется еще год, чтобы переделать.
  2. Как этого избежать? Нужно идти маленькими шагами, проверяя результат каждого шага и корректируя планы, если требуется. Избавит ли это от ошибки? Нет. Но в случае неправильно выбранного направления мы потеряем месяц, а не год. Месяц это не так дорого.

Если через месяц мы сделали прототип, показали клиентам, а они сказали: «это не то, что нам требуется». Мы можем просто прервать работу и заняться чем-нибудь более полезным, сэкономив тем самым 11 месяцев усилий 🙂

Всевозможные Agile, SCRUM и прочие итеративные подходы это как раз про это, а не про то что всем нравится постоянно собираться и устраивать демонстрации продуктов.

Читать далее →

Back to Top

SCRUM: scope спринта и срочная задача

25.09.2023   /   Практика  
Метки:, ,

При внедрении SCRUM часто возникает ситуация, когда в процессе спринта прилетает срочная задача. Например, критичный баг у клиента или на проде, задача от «большого начальника», который не привык ждать, и т.п. Возникает вопрос: «что делать и как с этим жить?».

Стандартно бывают несколько способов решить проблему:

  1. Если проект большой и над ним работает несколько продуктовых команд, то выделяют отдельную пожарную команду на исправление критичных багов.
  2. Всем прибегающим отказываем, мотивируя тем, что scope спринта не меняется и все будет, но в следующем спринте.
  3. Берем задачу в работу, потом в конце спринта констатируем, что вот опять не успели так как нежданчик прилетел. А если нежданчиков много, то можем и в принципе все планы не выполнить.

Разберем каждый из вариантов:

Пожарная команда — это наказание, быть в ней скучно. Чем ей заниматься, если багов не прилетает тоже непонятно. Могут, конечно, править старые баги или техническими долгами заниматься, но это все демотивирует разработчиков.

Не меняем scope спринта. Начнем с того, что всем не откажешь. Всегда есть человек с нужным административным ресурсом, которому отказать не удастся. Но даже если отказывать умеем, то что делать с лежащим продом? Обычно он не готов ждать до следующего спринта, чинить надо здесь и сейчас. Поэтому такой вариант ведет к бесконечным конфликтам с контрагентами, эскалациям, а делать все равно придется.

Берем задачу в работу, а потом жалуемся, что опять не успели и расстраиваемся по этому поводу и оправдываемся перед Product Owner’ом.

Читать далее →

Back to Top