Комментарии 21
Обычно, где-то на 80-90% находится несколько "незначительных" деталей, которые, действительно, выглядят как "Правильно ли мы отслеживаем показатели" и оказывается, что нифига ничего не работает как надо заказчику, а сдавать уже через неделю.
Да, я знаю, что во взрослых компаниях это всё должно учитываться в процессах, сроках и, вообще, такое не возможно.
А случается постоянно, даже если не особо инновационное что-то.
Но статья и подход хорошие, нужно стараться такое применять, чтобы потом людей против себя не настраивать, спасибо.
Обычно, где-то на 80-90% находится несколько «незначительных» деталей, которые, действительно, выглядят как «Правильно ли мы отслеживаем показатели» и оказывается, что нифига ничего не работает как надо заказчику, а сдавать уже через неделю.
Тут еще другой веселый момент есть: от людей, далёких от разработки софта (то есть, почти всех, кому софт пишется, собственно) очень тяжело получить хороший фидбек с начальных этапов — они сами еще не видят общей картины и не очень хорошо представляют, как оно вообще может быть. Тут можно что-то разрешить силами крутых аналитиков (которые собаку съели именно в переводе с путанного и невнятного человеческого на девелоперский и обратно), но таких сильно меньше, чем проектов, да и далеко не у всех есть на них деньги.
И отсюда получаем уловку-22: чтоб получить хороший фидбек, нужно выкатить клиенту что-то хорошо показываемое. Внутри этого может быть ад и израиль (и тогда вам придётся это заново переписать чуть позже), или же какая-то выстраданная опытом архитектура, но самое главное — показав это клиенту, вы получите от него куда более точный фидбек, чем ранее на этапе макетов и грандиозных планов. И не исключено, что фидбек будет таким, что придётся опять многое переписывать.
Собственно эти всякие скрамоаджайлы работают как раз на то, чтоб эта вот проблема не выливалась бы в превышение изначальных бюджетов и временных рамок на порядки, а всего лишь в разы.
Мне кажется, что в этом вопросе размер компании имеет значение. И у больших компаний гораздо больше шансов на стадии 80-90% обнаружить несколько «незначительных» деталей, которые рушат всё: много людей, много процессов, много решений, итераций, вот этого всего.
Мне подход зашёл, пробую, саму себя отслеживаю, когда на ранних этапах проекта начинаю врубать вкусовщину, запятые и прочие мелочи. Посмотрим, что из этого получится.
Мне подход зашёл, пробую, саму себя отслеживаю, когда на ранних этапах проекта начинаю врубать вкусовщину, запятые и прочие мелочи. Посмотрим, что из этого получится.
Конечо. И ровно эту проблему (в числе прочих) решает скрам. В нем DOD пишется перед тем, как задача взята в разработку, а ответственность за нее несет оунер. Если оунеру не нравится результат итерации, смотрят в DOD, и если результат ему соответствуют — задача оунера так ее переформулировать, чтобы в следующей итерации результат его устроил. Конечно, и заплатить за прошедшую итерацию тоже придется ему. Так у него появляется смысл заранее свои задачи продумывать.
А вот эти вот фидбеки, 360˚ — не знаю зачем они, но это никогда не работало и не будет работать. Потому что в действительности если кому-то из участников игра не нравится, игра сразу же прекращается. Для любого нормального человека любая критика его работы означает, что его исключили из игры. И скрам эту проблему тоже решает — игра заканчивается с окончанием итерации в любом случае. Плохо-ли, хорошо-ли, раунд закончен.
А вот эти вот фидбеки, 360˚ — не знаю зачем они, но это никогда не работало и не будет работать. Потому что в действительности если кому-то из участников игра не нравится, игра сразу же прекращается. Для любого нормального человека любая критика его работы означает, что его исключили из игры. И скрам эту проблему тоже решает — игра заканчивается с окончанием итерации в любом случае. Плохо-ли, хорошо-ли, раунд закончен.
Отзывы оунера после итераций и есть фидбеки, только более регулярные чем в статье.
В статье же основная идея не на фидбеках как таковых, а об их содержании на разных этапах проекта — когда только начался, в середине и ближе к завершению.
Что за 360˚, сам себе?
В статье же основная идея не на фидбеках как таковых, а об их содержании на разных этапах проекта — когда только начался, в середине и ближе к завершению.
А вот эти вот фидбеки, 360˚
Что за 360˚, сам себе?
Думаю, 360˚ это не "сам себе", а, скорее "со всех сторон". Такой, простите, gangbang feedback получается.
Отзывы оунера после итераций и есть фидбеки, только более регулярные чем в статье.
Да. Ровно это я и написал.
Но там нет, строго говоря, отзывов. Задача или сделана или не сделана. Третьего быть не может. Если есть какие-то пожелания, эти пожелания могут быть запланированы лишь в следующую итерацию.
В статье же основная идея не на фидбеках как таковых, а об их содержании на разных этапах проекта — когда только начался, в середине и ближе к завершению.
Вы исходите из идеи, что у проекта есть какие-то этапы. Это ложная идея, сделанная за итерацию работа полностью готова к поставке. Если вас не устраивает запятая, во-первых, орфография должна быть в DOD-е, а во-вторых, не принимайте просто задачу. Она уедет на следующую. И заплатите за нее вы, потому что это же вы не прописали орфографию в DOD-е, винить вам кроме себя некого.
Вы исходите из идеи, что у проекта есть какие-то этапы. Это ложная идея, сделанная за итерацию работа полностью готова к поставке.
Мы похоже с разными бэкграундами подходим к одной идее :)
Я работаю в продуктовой компании, где нет как оунера, который платит за итерации, так и самих итераций. У нас поквартальное планирование, где задачи/цели формулируются так, что можно измерить прогресс за квартал. Притом задач заведомо накидывается больше, чем можно сделать (чтобы не пришлось сидеть без дела, если оценки были неверные). В каждой задаче вполне можно выделить этапы. Очень часто мы пишем небольшие спеки, что и как собираемся делать для задачи. Они обсуждаются внутри команды. Это в какой-то мере отзыв на 10% стадию проекта.
В середине квартала у нас небольшое ревью — типа все ли двигается как надо и куда надо. Это как раз 50%.
Поэтому статья, что называется «зашла» для меня.
PS. Я очень поверхностно описал процесс планирования, понятно, что есть и годовые планы и планировать больше, чем можно сделать имеет более глубокую подоплеку. Весь этот процесс называется OKR.
Ну, по правде сказать, нет резона обсуждать какие-то минорные вещи, когда у вас такая крупная проблема. То есть, вот смотрите. Горит дом. А вы сидите в нем и обсуждаете, какие занавески на окнах лучше будут смотреться. Надо пожар тушить, а не занавески обсуждать.
Переходите на скрам. Будете в компании крутых ребят и забудете вообще про проблемы, с которыми до этого сталкивались.
Переходите на скрам. Будете в компании крутых ребят и забудете вообще про проблемы, с которыми до этого сталкивались.
По опыту, такое поражает как маленьких, так и больших.
НЛО прилетело и опубликовало эту надпись здесь
Первое: за годы фидбека Додо Пицца открыла сеть из 580+ пиццерий в 13 странах мира, которые посещают миллионы счастливых клиентов. Наша выручка больше 20 млрд рублей в год.
Второе: в технологическом блоге нашей компании мы рассказываем про культуру, делимся интересными переводами, говорим про наши технические решения. Мы бы с удовольствием передали ваш фидбек в отдел продукта, если бы он был более развернутым. Лучшим способом донести ваше впечатление от пиццы будет письмо на почту: feedback@dodopizza.com
Второе: в технологическом блоге нашей компании мы рассказываем про культуру, делимся интересными переводами, говорим про наши технические решения. Мы бы с удовольствием передали ваш фидбек в отдел продукта, если бы он был более развернутым. Лучшим способом донести ваше впечатление от пиццы будет письмо на почту: feedback@dodopizza.com
Нормальная, это какая? Среднестатичтическая (общая норма) или ваше субьективное понятие нормальности?
Я перепробовал много пицерий, пока не наткнулся на додо. Для нас лучше были только те, где цена была примерно х3, но это уже были не пиццерии, а рестораны.
Фидбек тоже работает. После пеерезда в ближайшей Додо пиццерии латте было горькое. 3 фидбека и поменяли кофе-машину, кофе стало шикарное.
Были в Геленжике, там горькое тоже, надо сделать пару фидбеков :)
Update:
Посмотрел попан с рейтингом… Чтож, получается я заагрился на тролля :)
Я перепробовал много пицерий, пока не наткнулся на додо. Для нас лучше были только те, где цена была примерно х3, но это уже были не пиццерии, а рестораны.
Фидбек тоже работает. После пеерезда в ближайшей Додо пиццерии латте было горькое. 3 фидбека и поменяли кофе-машину, кофе стало шикарное.
Были в Геленжике, там горькое тоже, надо сделать пару фидбеков :)
Update:
Посмотрел попан с рейтингом… Чтож, получается я заагрился на тролля :)
Очевидно, что необходимо контролировать не только результат, но и процесс выполнения работы чтобы следить за общим вектором движения. Очевидно, что не стоит заострять в этот момент внимание на деталях, а стараться доносить до исполнителей стратегию. Но как Вам удаётся при этом соблюсти баланс и не скатываться в микроменеджмент, есть ли какие-то практики кроме условных трех этапов, на которых исполнители получают фидбек? С большим уважением отношусь ко всему, что делает додо, хотелось бы больше деталей.
Пока что отдельных выкристаллизованных практик нет, но мы работаем над этим.
А пока считаем, что самый важный момент – это уточнение проблематики и формирование тех.задания. Если на этапе формирования технического задания все в команде проекта одинаково понимают а) какую конкретно проблему/задачу они хотят решить; б) какой конечный результата хотят получить, – если на этом этапе у всей команды синхрон, то микроменеджемент не грозит.
А пока считаем, что самый важный момент – это уточнение проблематики и формирование тех.задания. Если на этапе формирования технического задания все в команде проекта одинаково понимают а) какую конкретно проблему/задачу они хотят решить; б) какой конечный результата хотят получить, – если на этом этапе у всей команды синхрон, то микроменеджемент не грозит.
Один нюанс, который может все испортить. Очень часто исправление "мелочи" на этапе 99% означает переписывание половины бэкенда. И все возвращается к пункту n1. По-моему, статья пригодна только для фидбека по графическому дизайну и визуальным продуктам.
Исправление мелочи не должно так влиять на бэкэнд. Так случается тогда, когда архитектура плохая. Обычно хорошая архитектура держит большое кол-во мелких исправление.
Одна из причин почему затраты времени на архитектуру важны и нужны.
А если это пишет какой-нибудь фрилансер, ну или даже миддл/синьор с 2 годами опыта (сарказм), тогда да. они получают спек и под спец хардкодят всё, не думаю о будущем, не разбираясь с предметной области. Типо получили ТЗ, вот вам по ТЗ всё работает, а вот ваша мелочь выходит за рамки ТЗ и это будет стоить 50% от проекта…
Структура и архитектура бэкэнда, сделаная опытным человеком, который разобрался, разбил всё по сущностям, сделал слабую связанность — развивается годами и держит не только мелкие правки, а вполне даже смену(новый код) модулей приложения.
Одна из причин почему затраты времени на архитектуру важны и нужны.
А если это пишет какой-нибудь фрилансер, ну или даже миддл/синьор с 2 годами опыта (сарказм), тогда да. они получают спек и под спец хардкодят всё, не думаю о будущем, не разбираясь с предметной области. Типо получили ТЗ, вот вам по ТЗ всё работает, а вот ваша мелочь выходит за рамки ТЗ и это будет стоить 50% от проекта…
Структура и архитектура бэкэнда, сделаная опытным человеком, который разобрался, разбил всё по сущностям, сделал слабую связанность — развивается годами и держит не только мелкие правки, а вполне даже смену(новый код) модулей приложения.
Необходимость перехода от связи 1..1 к связи 1..n или даже m..n, например, всплывает иногда на этапе опытной эксплуатации или даже позже. Даже несмотря на заданные по десять раз вопросы на этапе проектирования.
Именно поэтому я упомянул предметную область.
Заказчик не знает как писать код и что такое архитектура. А разработчик делающий архитектуру должен знать, как бы :)
Вот у меня буквально пару недель назад случай. Я задал вопрос, он ответил, что 1 к 1. Ок, я пошел изучать. Вижу что 1 ко многим. Спрашиваю, нет говорит делай 1 к 1, настаивает на этом. Пришлось ему рассказывать о домах, стенах и комнатах и о том насколько легче щас заложить «10 пустых комнат», чем не заложить одну, а потом ломать «пол дома».
Ну и точно так же многое другое он просил, но после исследования оказалось, что надо закладывать структуру БД и архитектуру взаимодествия модулей иначе.
Заказчик не знает как писать код и что такое архитектура. А разработчик делающий архитектуру должен знать, как бы :)
Вот у меня буквально пару недель назад случай. Я задал вопрос, он ответил, что 1 к 1. Ок, я пошел изучать. Вижу что 1 ко многим. Спрашиваю, нет говорит делай 1 к 1, настаивает на этом. Пришлось ему рассказывать о домах, стенах и комнатах и о том насколько легче щас заложить «10 пустых комнат», чем не заложить одну, а потом ломать «пол дома».
Ну и точно так же многое другое он просил, но после исследования оказалось, что надо закладывать структуру БД и архитектуру взаимодествия модулей иначе.
Не всегда можно за время проекта выучить предметную область лучше заказчика. Особенно во всяких там нюансах. Например про то, что таможенная декларация может выпуститься с таможни не полностью узнали только через год реальной эксплуатации. А там куча всяких вариантов — и корректировка и возврат и импорт отдельной декларацией с тем же инвойсом (его куском). При этом заказчик это все знал, просто «так не бывает», а потом вдруг стало «бывать».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10/50/99: как давать обратную связь