Comments 3
Есть классы задач, где высокая неопределенность, технические риски без простого workaround, новая область деятельности для команды, постоянно изменяющиеся требования и приоритеты со стороны заказчика. И вот для подобных задач все описанное выше не помогает в решении проблем, а только мешает.
И в таких классах задач можно «договориться на берегу», просто требования к разработчику и его действиям (или говоря языком статьи нормы входа, деятельности) будут другие (выше) нежели к разрабу, работающего в более комфортных условиях. Меняются приоритеты/требования — короткие спринты/задачи, бьем задачи на элементарные (можно сделать в течение 1-2 дней, когда приоритеты не меняются). Перед началом разработки — поговорить с заказчиком, убедиться, что все понял правильно. Постоянно показывать результат, не изобретать велосипеды, не тупить над проблемой оптимизации сортировки гномиков и пр. Статья правильная и простая как 2х2 — четыре
Мне одному кажется, что прилетел капитан очевидность? Понятно же, что для определения проблем в чем-либо для начала неплохо бы определить понятие нормы или нормальности.
Понятие «неквалифицированного (и квалифицированного) исполнителя» в проектном менеджменте