Pull to refresh

Comments 5

Огонь! Всё, что вертелось у меня в голове, было наконец-то нормально сформировано в вашей статье. Теперь я знаю, как лучше отвечать на вопрос, когда именно будет выполнена задача, которую я ранее никогда не выполнял.

Добавил себе в закладки.

До этого момента я придерживался методологии "в сраку сроки", где задачи делятся на 2 типа:

  • Те, которые принесут реальную пользу бизнесу.

  • Те, которые по факту нафиг никому не нужны.

Задачи второго типа выкидывались и никогда не выполнялись, ну либо спускались на тормозах. Сэкономленное таким образом время тратилось на задачи первого типа.

На самом деле никто не отменяет разделения по важности (прибыльности) для бизнеса. Это другой срез, в рамках которого можно уже оценивать задачу, как исследовательскую, или типовую.

Статья получилось интересно - спасибо.
Я бы тут еще порассуждал на тему того, что задача может несколько раз менять вектор направления (из исследовательской в типовую и наоборот), в зависимости от изменения входящих данных и окружения.

Отдельная задача за время работы над ней вряд ли откатиться из типовой (если мы ее так определили) в исследовательскую, это достаточно редкая история. Скорее что-то такое найдем, что приведет к заведению новой исследовательской в процессе решения типовой. А вот если задачу оценили и она долго пролежала в беклоге, – здесь может быть все что угодно, и контекст изменяется непрерывно (как Вы верно заметили), и знания накапливаются.

За статью +, но у меня есть вопрос - на какие активности Вы отводите процесс Discovery? Кажется, статья именно про доставку - Delivery, в котом должны вместе работать несколько человек с разной специализацией (аналитик, разработчик и т.д.)

Sign up to leave a comment.

Articles