company_banner

10/50/99: как давать обратную связь

Автор оригинала: Brennan McEachran
  • Перевод
Обратная связь в компании, как Бэтмен в Готэме. Все ждут, что она прилетит и всех спасёт, направит на путь истинный. Но иногда, судя по ощущениям, вместо Бэтмена прилетает Джокер и рушит ваш проект.



Для нас, как и для большинства современных компаний, вопрос обратной связи стоит довольно остро: когда, кому и как её правильно давать. Мы пробуем разные подходы. Недавно нашли интересный материал, которым делимся с вами. Под катом про принцип обратной связи «10/50/99», как помогать и не рушить.



Сто лет назад я был веб-дизайнером и разработчиком на фрилансе. И мне довелось делать сайт для компании, которая занималась очисткой воды. Захватывающе, правда? Я был молод и, честно говоря, даже не понимал до конца, чем занимаются ребята в этой компании.

В самом начале проекта мы с CEO (заказчиком) были в равных позициях: он просто хотел крутой сайт. Как и я! Так что я пошёл и сделал. Вдохновлённый последними трендами дизайна и современными стандартами разработки, я придумал три шедевральных (как мне самому тогда казалось) варианта.

А потом случилось страшное — худший кошмар любого дизайнера: CEO попросил меня «сделать одно небольшое изменение», а, по сути, добавить уродливое дизайнерское решение, которое превращало мой шедевр из Великого в Мерзкий.

Меня накрыла фрустрация. Вспомнились все комиксы Дилберта, где генеральный директор врывается в последнюю минуту и рушит всё.

В тот момент я возненавидел сайт и проект. И единственное, чего мне хотелось — срочно покончить с этим. В течение многих лет я вспоминал этого генерального директора и думал: «С какой стати он пытался контролировать дизайн, если он платил мне деньги за то, чтобы я был дизайнером!? Он ничего не знает о дизайне!».

… Но потом я заметил, что начал давать обратную связь точно таким же образом.

Как всё испортить за один фидбек


Перенесёмся в наши дни: теперь я сам CEO (мой проект SoapBox). Со мной работали крутые спецы — рок-звезды в своих областях. Но когда они показывали мне свои работы и просили дать обратную связь, я ловил себя на мысли, что «превращаю их шедевры из Великих в Мерзкие».

Они усердно работали неделями, тщательно продумывая каждую деталь, а потом показывали мне окончательные результаты. И именно я в последнюю минуту разрушил их работу.

Я видел это по их лицам и вспоминал, как когда-то делал такое же лицо. Какого чёрта? Я не был плохим парнем. И не пытался всё испортить… но портил.

Результат их работы был великолепным, но он не встраивался в картину «нашего общего шедевра». Когда я замечал такое несоответствие, то предлагал решения из серии: «Хм, что-то тут не так, как-то криво, попробуйте изменить вот это...». Такое вторжение было моей попыткой связать симптомы с проблемой, о которой я не подозревал: у нас не было единого контекста проекта.

В следующий раз, когда я заметил «кривой шедевр», я уже не пытался его исправить. Я просто поделился общим контекстом проекта. И знаете что? ЭТО БЫЛО ЕЩЁ ХУЖЕ. На этот раз мой фидбек вызвал слёзы.

Посыл, который я им транслировал, скатился с «Исправьте одну вещь» до «Всё, что вы сделали за последние недели, было ошибкой».

Погрузить в контекст — хорошая идея, но время, которое я для этого выбрал — нет. Мне нужно было дать фидбек и жёсткое видение проекта на самой ранней стадии проекта. А чтобы это произошло, моей команде нужно было пригласить меня гораздо раньше, хоть это и казалось совершенно нелогичным (в конце концов, никто же не показываете учителю незаконченное задание в школе?).

Именно тогда меня спас подход 10/50/99. Он помог оградить людей от лишних расстройств и научил меня делиться недостающим контекстом в нужный момент.

Закольцовывая историю: в этот момент я понял, почему тот парень с водными фильтрами заставил меня сделать его сайт мерзким. Он хотел, чтобы сайт соответствовал его представлениям и задачам. Мне захотелось возмутиться «Что ж ты молчал раньше?», но на самом деле это я должен был запросить общий контекст в начале или запросить фидбек как только я приступил к делу, а не оттягивать до последнего момента, чтобы показать финальную версию проекта.

Далее будет разбор подхода 10/50/99, который убережёт ваши проекты от провала, а вашу команду от слёз.

Disclaimer: не я придумал этот подход. Уверен, что читал о 10/50/99 около 10 лет назад. Я хорошо помню это, но не могу найти пруф в Google. Кроме меня об этом писали один или два раза.

Что такое обратная связь 10/50/99?


Представим, что любой проект можно разбить на три фазы готовности — 10%, 50% и 99%, где:

  • 10% готовность — почти ничего не сделано;
  • 50% готовность — главные составляющие проекта начинают соединяться друг с другом;
  • 99% готовность — всё готово, осталось чекнуть орфографию, грамматику и т. д.



10/50/99% обратной связи соответствуют тому объёму фидбека, которым вы можете делиться на каждом из этих этапов работы.
Суперочевидно и суперважно: единственная обратная связь, которую вы можете дать на этапе 10% — это 10% обратная связь. Вы не должны давать 10% обратную связь на заключительном 99% этапе. И наоборот: вы не можете дать 99% обратную связь на этапе 10%.
Идея подхода заключается в том, сколько времени и энергии этот тип обратной связи экономит. Когда это становится общим правилом предоставления обратной связи для всех в компании, вырабатывается единый язык общения. Например:

Исполнитель показывает первые наработки: «Я на стадии 10%».

Кто-то указывает на опечатку: «Вот тут неправильно написано...».

Буквально все остальные в комнате: «Мы сейчас на уровне 10%. Прибереги это на потом».

Стадия 10% готовности проекта


Самая ранняя стадия любого проекта — это стадия 10% готовности. Когда проект — это только эскиз, контур, маркированный список, бриф. Иногда эта стадия занимает всего 10 минут.



На этом этапе нет ничего «хорошего», что хотелось бы показывать другим. И это самая сложная обратная связь, которую приходится давать и получать, потому что люди не любят показывать свою «нехорошую» работу коллегам и начальникам.

Мне кажется, что особенно сложно это даётся джунам: как показать проект, готовый на 10% и выглядеть при этом круто? Чувство боли неизбежно, потому что кажется, что ты показываешь незаконченную работу. Как можно показать жизнеспособность проекта, не углубляясь в детали?

Сам проект и исполнитель находятся в психологически «небезопасном» положении в этот момент, поэтому важно быть деликатным и сильно продумывать обратную связь. Одно неосторожное слово может загубить проект. Серьёзно.

Как не давать обратную связь на этапе 10%


Из всех этапов именно здесь люди, дающие обратную связь, чаще всего допускают ошибки.

Например, дизайнер приходит с первым драфт-макетом, а ведущий дизайнер даёт фидбек: «Логотип не отцентрован». Это заставляет дизайнера думать так: «Мой босс думает, что я плохой дизайнер, что я слишком мало старался, что я должен был уделить больше внимания деталям». Он захочет сделать работу лучше и в следующий раз на встречу по 10% готовности придёт с цветным Hi-Fi макетом и полным фаршем.

Как давать обратную связь на этапе 10%


На этапе 10% готовности вы должны давать обратную связь про общее видение (единый вижн) и направление, в котором идёт работа. Исполнителям должно быть легко изменить текущее направления работы без ощущения, что всё пошло насмарку. Ничьи чувства не должны быть задеты, даже если все в переговорке решат «знаете, вся эта затея — пустая трата времени, расходимся».

На 10% стадии готовности вы должны обсуждать сам проект:

  • Какая цель этого проекта?
  • Какой желаемый результат?
  • Зачем мы вообще делаем этот проект?

Всё это вы должны обсудить сейчас, чтобы найти общий язык, направление и видение, которые будут драйвить проект. Фиксируя договорённости на ранней стадии процесса, вы спасаете себя (и свою команду) от болезненных и ненужных дебатов позже (ближе к срокам срыва проекта). Другими словами: если кто-то хочет обсудить бриф проекта, он должен сделать это сейчас или пусть замолкнет навеки.
Делайте заметки. Записывайте решения, которые пришли вам в голову на этом этапе. Позднее вы пожалеете, если не сделаете этого. Они понадобятся вам в будущем, если вы решите что-то изменить.
И это именно то, чего я добиваюсь: будучи CEO, я хочу обсуждать концепцию. Потому что на этом этапе я могу привнести ценность.

По мере того как ваша команда углубляется в проект, вы должны (в идеале) давать всё меньше и меньше обратной связи. Потому что они — эксперты в своей области, а вы — нет. Как лидер, вы можете и должны предлагать свою обратную связь на самом раннем этапе, чтобы перевести несогласованные идеи в правильное направление. Это намного дешевле сделать сейчас, чем позже.

Стадия 50% готовности проекта


Это первый черновик. Бесцветный макет. И если вы думаете, что сотрудникам сложно выкатывать на всеобщее обозрение 10% готовность, то 50% этап готовности может быть ещё хуже. Ведь на нём намеренно показывают свою незаконченную работу.



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

Не мельчите. Если вы будете давать фидбек по мелким деталям на этом этапе, вы всё испортите. Люди расценят ваши комментарии как критику, а не как обратную связь. В следующий раз они придут с тремя готовыми версиями проекта и просто попросят выбрать одну из них. И не будут вступать в диалог. И будут разочарованы.

Как давать обратную связь на этапе 50%


Чтобы дать обратную связь на этом этапе, достаньте заметки, которые вы делали на этапе 10%. Посмотрите на вижн и направление, которые вы согласовали с командой тогда, и проверяйте, соответствует ли 50% проекта тем обсуждениям.

Середина процесса — сложная стадия. Направление и цель больше не обсуждаются, но и к словам ещё придираться нельзя. Здесь вы смотрите на общую структуру или макет. Это также правильный этап для получения обратной связи от других отделов или команд, если в этом есть необходимость. С одной стороны, проект достаточно далеко продвинулся, чтобы другие отделы получили чёткое представление о целях и брифе, с другой стороны, всё ещё есть время на изменения на основе фидбека.
Попросите человека, ведущего проект, озвучить следующее:

«Мы на стадии 50% готовности. Цели, которые мы согласовали для проекта:

  • Цель номер один.
  • Цель номер два.
  • Цель номер три.

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

  • Пример номер один.
  • Пример номер два.
  • Пример номер три».

Стадия 99% готовности проекта


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



Вся стадия 99% про маленькие детали. Наконец-то пришло время придираться и докапываться! Работают ли ссылки? Правильно ли мы отслеживаем показатели, которые нам нужны? Есть ли опечатки? Есть ли какие-нибудь баги?

Сейчас уже нельзя возвращаться к обсуждению цели или структуру. С этим разобрались в прошлом. Вернитесь к тем самым заметкам, если это необходимо.

Как давать обратную связь на этапе 99%


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

И вообще… Если у вас хорошая команда, которой вы доверяете, можете скипнуть этот этап. Ваше участие уже не требуется. Доверьте им их работу и не доводите до микроменеджмента.

Однако сложности могут возникнуть и тут. На протяжении всего проекта каждый умирал от желания дать 99% обратной связи в неподходящее время. И теперь, когда настало подходящее время для этого, люди могут пытаться вернуться к 10% обратной связи. Снова и снова. Ваша задача как лидера — просто убедиться, что они этого не делают.

Ещё бывают случаи, когда 99% обратная связь становится кошмаром для её получателя. Мозг отключается, включается автопилот. И человек начинает вносить все изменения, о которых ему говорят. Ваша задача — напомнить о целях проекта, чтобы исполнители могли отделить хороший фидбек от плохого.

В дополнение


Будет немного трудно
  1. Трудно, если в вашей команде нет атмосферы психологической безопасности. Легко, если она есть.

    Естественно все боятся 10% и 50% обратной связи, потому что больно показывать незаконченную работу людям, на которых вы хотите произвести впечатление.

    Вполне логично, что у сотрудников есть этот страх — на протяжении всей школы и универа вы получаете оценки по готовой домашке или контрольной. А теперь вдруг вам придётся раскрепоститься, с самого начала привлекать людей и быть готовым к тому, что проекты будут свёрнуты ещё до того, как кто-то действительно увидит, на что вы способны.

    Как лидер, вы должны создать психологически безопасное пространство, в котором ваша команда будет чувствовать себя комфортно, делясь своей работой на каждом этапе этого процесса. Когда вы достигнете этого уровня, результаты будут феноменальными. Люди будут чувствовать себя более комфортно, делясь своей работой и своим мнением.
  2. Трудно сдерживать себя, когда очень хочется поделиться своим мнением.

    По-моему опыту, любому лидеру трудно разнести обратную связь по стадиям и не тыкать в орфографические ошибки на стадии 10%.

    Всё усложняется тем, что мало кто умеет давать обратную связь по принципу 10/50/99. Этот навык надо тренировать, а большинство людей считают, что всё должно происходить естественным образом. Кроме того, люди часто путают конструктивную обратную связь с излишне резкой критикой вне контекста. Люди могут думать, что это нормально быть резкими, потому что они открыты и честны, но это не одно и то же. Чрезмерная резкость или неправильная обратная связь на неправильном этапе только подогреют страхи сотрудников. В результате уровень психологической безопасности в вашей команде снизится.

Три совета по подходу
После нескольких лет использования подхода я сформулировал советы, которые помогут подходу 10/50/99 работать на вас и вашу команду.

  1. Сопоставьте правильную обратную связь с правильной стадией.

    Хотя я уже сто раз сказал об этом в статье, стоит повторить ещё раз. И ещё раз. И ещё раз. Потому что это самая трудная для осознания вещь.

    Чтобы этот подход к обратной связи работал, каждый участник должен быть ответственным за предоставление правильной обратной связи в нужное время. То есть каждый раз, когда фидбек не метчиться со стадией готовности проекта, надо указывать на это и не принимать. Каждый раз.
  2. Работайте над формированием доверия.

    Ваша команда должна верить, что вы не хотите разрушить их работу. А вы, как руководитель, должны верить, что ваша команда не будет игнорировать фидбек, которым вы делитесь.

    Формирование доверия — долгая история, но оно того стоит. Можно дать им почитать эту статью перед внедрением подхода, чтобы все были в едином информационном поле.
  3. Если вы пропустили один из этапов обратной связи, что ж, вам не повезло.

    Если сотрудник показывал 10% готовность, а вас там не было. Плохо. Теперь вам нужно разузнать их 10% решения и прийти на 50% обратную связь.

    Или признать свои ошибки и попросить перезагрузить весь проект с нуля, из-за того, что вы когда-то не смогли найти время.

    И всё же, если вы видите что-то впервые, вам должно быть позволено дать 10% обратную связь. Просто очень чётко объясните, что у вас не было возможности обсудить 10% материал, поэтому вы собираетесь поделиться своими 10% фидбеком сейчас. В следующий раз давайте его с самого начала.

Виды обратной связи от CEO
Будучи лидером, чётко определяйте тип обратной связи, которую вы даёте.

Вы обладаете большой властью. Когда вы даёте обратную связь, ваша команда может воспринять её как закон, вступивший в силу. Иногда это очень хорошо, а иногда вредно.

Вот почему важно чётко представлять себе тип обратной связи, которую вы даёте, когда вы её даёте. Моя личная таксономия типов фидбека выглядит так:

  1. Размышления вслух. Этот тип обратная связи именно об этом — просто мысли вслух. Просто мимолетная мысль, которая случайно возникла у вас в голове и вырвалась изо рта, когда кто-то стоял рядом с вами. Это не та обратная связь, которая должна менять ход проекта.
  2. Мнение одного человека. Это тип обратной связи, когда вы предлагаете свою собственную точку зрения, но не как руководитель, а как человек, заинтересованный в этом проекте. Её следует оценивать с таким же приоритетом, как и фидбек любого другого члена команды.
  3. Внушение. Это уже не «мнение одного человека», но всё ещё не директива для команды. Этот тип обратной связи — мнение одного человека, которое сформировалось у него через опыт и усвоенные уроки. Но это не значит, что команда не может не прислушаться к фидбеку.
  4. Я сказал. Лидер говорит команде, как нужно делать. Просто и ясно. Иногда это необходимое зло, но им нельзя пользоваться чрезмерно.

Dodo Engineering
О том, как разработчики строят IT в Dodo

Похожие публикации

Комментарии 22

    +4

    Обычно, где-то на 80-90% находится несколько "незначительных" деталей, которые, действительно, выглядят как "Правильно ли мы отслеживаем показатели" и оказывается, что нифига ничего не работает как надо заказчику, а сдавать уже через неделю.
    Да, я знаю, что во взрослых компаниях это всё должно учитываться в процессах, сроках и, вообще, такое не возможно.
    А случается постоянно, даже если не особо инновационное что-то.


    Но статья и подход хорошие, нужно стараться такое применять, чтобы потом людей против себя не настраивать, спасибо.

      +3
      Обычно, где-то на 80-90% находится несколько «незначительных» деталей, которые, действительно, выглядят как «Правильно ли мы отслеживаем показатели» и оказывается, что нифига ничего не работает как надо заказчику, а сдавать уже через неделю.

      Тут еще другой веселый момент есть: от людей, далёких от разработки софта (то есть, почти всех, кому софт пишется, собственно) очень тяжело получить хороший фидбек с начальных этапов — они сами еще не видят общей картины и не очень хорошо представляют, как оно вообще может быть. Тут можно что-то разрешить силами крутых аналитиков (которые собаку съели именно в переводе с путанного и невнятного человеческого на девелоперский и обратно), но таких сильно меньше, чем проектов, да и далеко не у всех есть на них деньги.

      И отсюда получаем уловку-22: чтоб получить хороший фидбек, нужно выкатить клиенту что-то хорошо показываемое. Внутри этого может быть ад и израиль (и тогда вам придётся это заново переписать чуть позже), или же какая-то выстраданная опытом архитектура, но самое главное — показав это клиенту, вы получите от него куда более точный фидбек, чем ранее на этапе макетов и грандиозных планов. И не исключено, что фидбек будет таким, что придётся опять многое переписывать.

      Собственно эти всякие скрамоаджайлы работают как раз на то, чтоб эта вот проблема не выливалась бы в превышение изначальных бюджетов и временных рамок на порядки, а всего лишь в разы.
        +1
        Мне кажется, что в этом вопросе размер компании имеет значение. И у больших компаний гораздо больше шансов на стадии 80-90% обнаружить несколько «незначительных» деталей, которые рушат всё: много людей, много процессов, много решений, итераций, вот этого всего.

        Мне подход зашёл, пробую, саму себя отслеживаю, когда на ранних этапах проекта начинаю врубать вкусовщину, запятые и прочие мелочи. Посмотрим, что из этого получится.
        –2
        Конечо. И ровно эту проблему (в числе прочих) решает скрам. В нем DOD пишется перед тем, как задача взята в разработку, а ответственность за нее несет оунер. Если оунеру не нравится результат итерации, смотрят в DOD, и если результат ему соответствуют — задача оунера так ее переформулировать, чтобы в следующей итерации результат его устроил. Конечно, и заплатить за прошедшую итерацию тоже придется ему. Так у него появляется смысл заранее свои задачи продумывать.
        А вот эти вот фидбеки, 360˚ — не знаю зачем они, но это никогда не работало и не будет работать. Потому что в действительности если кому-то из участников игра не нравится, игра сразу же прекращается. Для любого нормального человека любая критика его работы означает, что его исключили из игры. И скрам эту проблему тоже решает — игра заканчивается с окончанием итерации в любом случае. Плохо-ли, хорошо-ли, раунд закончен.
          0
          Отзывы оунера после итераций и есть фидбеки, только более регулярные чем в статье.

          В статье же основная идея не на фидбеках как таковых, а об их содержании на разных этапах проекта — когда только начался, в середине и ближе к завершению.

          А вот эти вот фидбеки, 360˚

          Что за 360˚, сам себе?
            +1

            Думаю, 360˚ это не "сам себе", а, скорее "со всех сторон". Такой, простите, gangbang feedback получается.

              +1
              Кажется, вы только что изобрели новый термин!
              0
              Отзывы оунера после итераций и есть фидбеки, только более регулярные чем в статье.

              Да. Ровно это я и написал.

              Но там нет, строго говоря, отзывов. Задача или сделана или не сделана. Третьего быть не может. Если есть какие-то пожелания, эти пожелания могут быть запланированы лишь в следующую итерацию.

              В статье же основная идея не на фидбеках как таковых, а об их содержании на разных этапах проекта — когда только начался, в середине и ближе к завершению.

              Вы исходите из идеи, что у проекта есть какие-то этапы. Это ложная идея, сделанная за итерацию работа полностью готова к поставке. Если вас не устраивает запятая, во-первых, орфография должна быть в DOD-е, а во-вторых, не принимайте просто задачу. Она уедет на следующую. И заплатите за нее вы, потому что это же вы не прописали орфографию в DOD-е, винить вам кроме себя некого.
                +1
                Вы исходите из идеи, что у проекта есть какие-то этапы. Это ложная идея, сделанная за итерацию работа полностью готова к поставке.


                Мы похоже с разными бэкграундами подходим к одной идее :)

                Я работаю в продуктовой компании, где нет как оунера, который платит за итерации, так и самих итераций. У нас поквартальное планирование, где задачи/цели формулируются так, что можно измерить прогресс за квартал. Притом задач заведомо накидывается больше, чем можно сделать (чтобы не пришлось сидеть без дела, если оценки были неверные). В каждой задаче вполне можно выделить этапы. Очень часто мы пишем небольшие спеки, что и как собираемся делать для задачи. Они обсуждаются внутри команды. Это в какой-то мере отзыв на 10% стадию проекта.

                В середине квартала у нас небольшое ревью — типа все ли двигается как надо и куда надо. Это как раз 50%.

                Поэтому статья, что называется «зашла» для меня.

                PS. Я очень поверхностно описал процесс планирования, понятно, что есть и годовые планы и планировать больше, чем можно сделать имеет более глубокую подоплеку. Весь этот процесс называется OKR.
                  –1
                  Ну, по правде сказать, нет резона обсуждать какие-то минорные вещи, когда у вас такая крупная проблема. То есть, вот смотрите. Горит дом. А вы сидите в нем и обсуждаете, какие занавески на окнах лучше будут смотреться. Надо пожар тушить, а не занавески обсуждать.
                  Переходите на скрам. Будете в компании крутых ребят и забудете вообще про проблемы, с которыми до этого сталкивались.
            0

            По опыту, такое поражает как маленьких, так и больших.

              –1
              И вот представьте насколько все плохо, если ГОДЫ фидбека так и не заставили додо пиццу делать нормальную пиццу -=(**
                +4
                Первое: за годы фидбека Додо Пицца открыла сеть из 580+ пиццерий в 13 странах мира, которые посещают миллионы счастливых клиентов. Наша выручка больше 20 млрд рублей в год.

                Второе: в технологическом блоге нашей компании мы рассказываем про культуру, делимся интересными переводами, говорим про наши технические решения. Мы бы с удовольствием передали ваш фидбек в отдел продукта, если бы он был более развернутым. Лучшим способом донести ваше впечатление от пиццы будет письмо на почту: feedback@dodopizza.com
                  +5
                  Нормальная, это какая? Среднестатичтическая (общая норма) или ваше субьективное понятие нормальности?

                  Я перепробовал много пицерий, пока не наткнулся на додо. Для нас лучше были только те, где цена была примерно х3, но это уже были не пиццерии, а рестораны.

                  Фидбек тоже работает. После пеерезда в ближайшей Додо пиццерии латте было горькое. 3 фидбека и поменяли кофе-машину, кофе стало шикарное.

                  Были в Геленжике, там горькое тоже, надо сделать пару фидбеков :)

                  Update:
                  Посмотрел попан с рейтингом… Чтож, получается я заагрился на тролля :)
                  0

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

                    0
                    Пока что отдельных выкристаллизованных практик нет, но мы работаем над этим.

                    А пока считаем, что самый важный момент – это уточнение проблематики и формирование тех.задания. Если на этапе формирования технического задания все в команде проекта одинаково понимают а) какую конкретно проблему/задачу они хотят решить; б) какой конечный результата хотят получить, – если на этом этапе у всей команды синхрон, то микроменеджемент не грозит.
                    0

                    Один нюанс, который может все испортить. Очень часто исправление "мелочи" на этапе 99% означает переписывание половины бэкенда. И все возвращается к пункту n1. По-моему, статья пригодна только для фидбека по графическому дизайну и визуальным продуктам.

                      0
                      Исправление мелочи не должно так влиять на бэкэнд. Так случается тогда, когда архитектура плохая. Обычно хорошая архитектура держит большое кол-во мелких исправление.
                      Одна из причин почему затраты времени на архитектуру важны и нужны.

                      А если это пишет какой-нибудь фрилансер, ну или даже миддл/синьор с 2 годами опыта (сарказм), тогда да. они получают спек и под спец хардкодят всё, не думаю о будущем, не разбираясь с предметной области. Типо получили ТЗ, вот вам по ТЗ всё работает, а вот ваша мелочь выходит за рамки ТЗ и это будет стоить 50% от проекта…

                      Структура и архитектура бэкэнда, сделаная опытным человеком, который разобрался, разбил всё по сущностям, сделал слабую связанность — развивается годами и держит не только мелкие правки, а вполне даже смену(новый код) модулей приложения.
                        0
                        Необходимость перехода от связи 1..1 к связи 1..n или даже m..n, например, всплывает иногда на этапе опытной эксплуатации или даже позже. Даже несмотря на заданные по десять раз вопросы на этапе проектирования.
                          0
                          Именно поэтому я упомянул предметную область.
                          Заказчик не знает как писать код и что такое архитектура. А разработчик делающий архитектуру должен знать, как бы :)
                          Вот у меня буквально пару недель назад случай. Я задал вопрос, он ответил, что 1 к 1. Ок, я пошел изучать. Вижу что 1 ко многим. Спрашиваю, нет говорит делай 1 к 1, настаивает на этом. Пришлось ему рассказывать о домах, стенах и комнатах и о том насколько легче щас заложить «10 пустых комнат», чем не заложить одну, а потом ломать «пол дома».
                          Ну и точно так же многое другое он просил, но после исследования оказалось, что надо закладывать структуру БД и архитектуру взаимодествия модулей иначе.
                            0
                            Не всегда можно за время проекта выучить предметную область лучше заказчика. Особенно во всяких там нюансах. Например про то, что таможенная декларация может выпуститься с таможни не полностью узнали только через год реальной эксплуатации. А там куча всяких вариантов — и корректировка и возврат и импорт отдельной декларацией с тем же инвойсом (его куском). При этом заказчик это все знал, просто «так не бывает», а потом вдруг стало «бывать».

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое