Ваши вопросы относятся к теме развития людей и команды, это большая и важная тема. Может быть напишу и по ней статью.
Кратко по тому, как работаем мы: команды периодически перетасовываем по чуть-чуть, но стараемся сделать так, чтобы в каждой команде всегда был опытный проектировщик, в идеале — два. Проектирование всегда парное, если есть только один сильный проектировщик — он проектирует парно с кем-то из способных новичков, обычно за несколько месяцев тот прокачивается до хорошего уровня.
Пара проектировщиков и аналитик начинают проектирование как можно раньше, команда в это время занимается понятными задачами, техдолгом, поддержкой продуктива. По мере понимания задачи команда подключается к прототипированию, проработке конкретных деталей.
Из личного опыта я усвоил, что командная работа от него спасает не всегда. «Закапываться» и «залипать» впятером можно так же, как и одному.
На мой взгляд решение стоит искать в других подходах (предупреждаю, они не всем подойдут):
Не пытаться придумать заранее детальное решение всех проблем. Сделать схему по-крупному с зависимостями, а дальше двигаться: каждый спринт брать кусочек, проектировать и сразу делать. Если при этом возникнут проблемы с уже сделанным — дорабатывать старое или даже переделывать (переделки очень тонкий момент, обсудите с заказчиком заранее). Со временем ваше понимание и знания увеличиваются и вы находите решения, которые не нашли бы находясь в «аналитическом параличе».
Урезать функциональность. Бывает просят кучу вещей, которые друг другу противоречат. Тогда помогает сначала понять, что действительно важно, донести это до заказчика/стейкхолдера и выкинуть лишнее. Так вы уменьшите количество связанных задач и распутать «клубок» будет легче.
Проектировать от кейсов пользователей. Обычно кейсы реальной жизни противоречат друг другу реже, чем написанные кем-то «требования».
Периодически оценивать трудоемкость фич. Наверняка у вас есть максимальная цена в совокупности для всего проекта. Чаще всего нет смысла проектировать фичи, которые вы не будете делать. Если вы оцените весь «клубок» и выясните, что у вас превышение бюджета в два раза переходите к пункту «урезать функциональность».
Чаще обсуждать проблему. Я имею ввиду не только обсуждения в команде, но и с владельцем продукта, заказчиком. Совет спорный, все таки это затраты времени, но проверено на себе: в случае «паралича» это встряхивает проектировщиков и некоторые проблемы решаются сами собой.
Да, у нас есть шаблон, так и называется «Шаблон тех. проекта». А еще есть чеклисты по инициации проектирования, организации обсуждений, исследованию. Это все не строго обязательно, просто упрощает документирование.
У нас документ «по-крупному» должен содержать 4 раздела:
В разделе «Открытые вопросы» зафиксированы текущие вопросы, которые необходимо обсудить на ближайшем совещании, либо вопросы, на которые нужно ответить к ближайшему обсуждению.
Раздел «Решения» состоит из текущих прорабатываемых вариантов решений, итоговой оценки трудоемкости, мокапов, скриншотов прототипов. Для предлагаемых вариантов выделяются плюсы и минусы в виде таблицы.
В раздел «Приложения» переносятся:
закрытые вопросы;
результаты исследований;
ссылки на связанные документы;
прочая вспомогательная информация.
При согласовании документа с заказчиком, рекомендуется выделять вверху документа раздел «Аннотации» с кратким содержанием и выводами.
При этом документы получаются короткими, воду лить не нужно. Описать решение тому, кто его придумал обычно не сложно, плюсы и минусы тоже. В документ пишут все участники команды. Проектная документация на спринт команды из 6 человек — 5-6 страниц (с картинками).
Вы правы, со временем так или иначе начинаешь работать эффективнее и процессы становятся отлаженными.
Почему я упомянул Scrum?
Потому что он в моем случае подталкивал к таким решениям. Командная работа подталкивает к командному проектированию. Итерационная разработка заставляет искать способы ускорения процесса. Ретро это отличный способ работы над улучшениями — вопросы проектирования на ретро поднимаются чаще всех остальных, даже сейчас.
Уже ответили про документирование, примерно того же мнения придерживаюсь и я.
Вы подняли интересную тему «analysis paralysis». Я с ней сталкивался сам, пытался решить разными способами и Вы совершенно правы: нанять аналитика это не решение, он впадет в такой паралич часто быстрее разработчика. Проблема сложная и возможно заслуживает отдельного анализа и статьи. Может быть поделитесь другими сложностями, решение которых лично Вам было бы интересно?
А если изучение предметной области занимает месяцев 3..9?
У нас с этим попроще, но попробую предложить решения:
Исследовать по кусочкам, если это возможно. Сначала разбить по-крупному, а дальше в каждый спринт брать по одной теме для глубокой проработки и реализации. Повторюсь, если такое возможно в конкретной предметной области
Увеличить количество аналитиков/развивать компетенции аналитиков у других участников команды. Например, у тестировщиков.
А если не секрет какая предметная область требует изучения нормативной документации по 9 месяцев?
Необходимый минимум для кого?
В нашем случае (продуктовая разработка) получается для команды и заинтересованных лиц. Но и на практике внедрений и внешних проектов заказчики (не все конечно) готовы идти на компромиссы и отказываться от жесткого ТЗ.
«бумажки» пишут как раз не программисты
Где как, но чаще архитекторы и аналитики, вы правы. Я имел ввиду именно проектную документацию (ТЗ, спецификации).
Как этот процес работает с контрактами Time & Material и Fixed Price?
Сильно зависит от заказчика, но может работать. Коллега из отдела внедрения недавно писал статью по опыту недавних внедрений как раз по fixed price и time&material.
Не могли бы Вы сказать какие проекты и в каких предметных областях вы реализовали по такой методологии?
Конкретные проекты назвать не могу, предметная область — ЕСМ и все что вокруг ЕСМ.
Как вы «встраиваете» работу с аналитиком в свою реализацию Scrum?
Аналитик физически в команде, активно участвует в исследовании, проектировании, тестирует, занимается документацией и справкой. Задач по ходу спринта хватает для 100% загрузки.
Куда относится работа по «требуется исследование предметной области, конкурентов, кейсов работы пользователей»
Все в рамках проектирования в итерации. Если это будет отдельно, а потом отдельно проектирование, а потом отдельно реализация это уже не совсем Scrum :-)
Почему работа по «исследование… конкурентов» относится к самому циклу разработки продукта/решения?
Потому что это нужно для проектирования, чтобы понять полную картину. Конечно можно исследования проводить заранее, но на практике они устаревают и забываются к началу итерации, поэтому делаем все вместе.
И как так получилось что «программисты пишут бумажки» и какие? да еще и «на выброс»?
Мы сейчас на выброс ничего не пишем, я собственно об этом и писал. Документируем необходимый минимум, в основном в виде мокапов.
А вообще «программисты пишут бумажки» это распространенная практика, особенно когда заказчик требует тщательно описать все в ТЗ, правда потом его сам не всегда читает.
Сколько у вас примерно «стоит» проектирование?
Посмотрел по прошлому релизу: проектирование + разработка, тестирование и поддержка реализованного (баги, развертывание, продуктивы и т.д.) занимают одинаковое время.
Как новый участник проекта получает необходимие знания по проекту?
Обучение внутри команды + самостоятельно по справке к продукту, парное программирование, своя wiki по архитектуре и приемам разработки, привлечение к проектированию и планированию.
Обычно этого достаточно, чтобы освоиться за пару месяцев.
Владелец продукта ставит перед командой задачу: что и зачем нужно сделать, на уровне его видения. Дальше проектируем: разбираемся как будем делать, потом декомпозируем на мелкие части и оцениваем.
Похоже на планирование, но:
задачи бывают сложные, за один день планирования спринта успеть физически невозможно.
часто до того, как начать делать нужно получить одобрение владельца продукта и заказчика/стейкхолдера
видение владельца продукта бывает поверхностным, требуется исследование предметной области, конкурентов, кейсов работы пользователей
Тестировщики и аналитики по-хорошему это участники процесса проектирования, демо для них не нужно.
Если говорить про остальных «заинтересованных лиц», то в любом случае придется потратить время на взаимодействие. Либо в виде демо, либо в виде постоянных ответов на их вопросы, потому что сами они могут неправильно понять что вы делаете и зачем.
Мне кажется «скрам-хайп» был актуален лет 5 назад, как раз тогда мы на него и перешли. С тем, что он с тех пор набил оскомину соглашусь, но все таки методологий управления разработкой не так уж и много, повторения неизбежны.
А фишка в том, что взять методологию — это половина дела, надо еще адаптировать ее под себя. И я как раз scrum не пиарю, он в этом не нуждается, а просто делюсь наблюдениями за эти 5 лет.
Надеюсь, что нет.
Ничего против них не имею, но именно в концепции аналитика-проектировщика есть определенные минусы, которые в моем случае получилось устранить за счет проектирования всей командой.
Одна из целей хакатонов — смена обстановки, в этом вы правы. При этом это очень свободный формат: мы сами выбрали что делать, как делать, где и каким составом. В следующий раз, например, мы скооперовались с ребятами, с которыми вообще раньше не пересекались и это тоже был новый опыт. Но все-таки самое главное в хакатоне на мой взгляд — «импровизирование», а именно возможность собрать свою команду и реализовать идею.
Относительно бесплатных фич — не знаю финансовых подробностей организации хакатона, естественно была бесплатная еда, и за эти выходные нам в итоге заплатили как за рабочие дни. Для руководства наверное это хороший способ увидеть новые идеи и получить прототипы. Я не вижу в этом ничего плохого, в этой ситуации выигрывают обе стороны.
С учетом того, что полезной и реализуемой оказывается примерно 1 идея из 10 и на доведение ее до ума нужно времени в 10 раз больше, чем на прототип я бы поспорил с тем, что это «бесплатные фичи».
А главная разница между обычными рабочими днями и хакатоном в том, что мы были абсолютно самостоятельны в выборе темы, формата работы, команды и т.д. Собственно в тот момент я получал фан и не думал о том, что эту фичу мы потом прикрутим к продукту уже в обычное рабочее время.
Кратко по тому, как работаем мы: команды периодически перетасовываем по чуть-чуть, но стараемся сделать так, чтобы в каждой команде всегда был опытный проектировщик, в идеале — два. Проектирование всегда парное, если есть только один сильный проектировщик — он проектирует парно с кем-то из способных новичков, обычно за несколько месяцев тот прокачивается до хорошего уровня.
Пара проектировщиков и аналитик начинают проектирование как можно раньше, команда в это время занимается понятными задачами, техдолгом, поддержкой продуктива. По мере понимания задачи команда подключается к прототипированию, проработке конкретных деталей.
Из личного опыта я усвоил, что командная работа от него спасает не всегда. «Закапываться» и «залипать» впятером можно так же, как и одному.
На мой взгляд решение стоит искать в других подходах (предупреждаю, они не всем подойдут):
Да, у нас есть шаблон, так и называется «Шаблон тех. проекта». А еще есть чеклисты по инициации проектирования, организации обсуждений, исследованию. Это все не строго обязательно, просто упрощает документирование.
У нас документ «по-крупному» должен содержать 4 раздела:
При этом документы получаются короткими, воду лить не нужно. Описать решение тому, кто его придумал обычно не сложно, плюсы и минусы тоже. В документ пишут все участники команды. Проектная документация на спринт команды из 6 человек — 5-6 страниц (с картинками).
Почему я упомянул Scrum?
Потому что он в моем случае подталкивал к таким решениям. Командная работа подталкивает к командному проектированию. Итерационная разработка заставляет искать способы ускорения процесса. Ретро это отличный способ работы над улучшениями — вопросы проектирования на ретро поднимаются чаще всех остальных, даже сейчас.
Вы подняли интересную тему «analysis paralysis». Я с ней сталкивался сам, пытался решить разными способами и Вы совершенно правы: нанять аналитика это не решение, он впадет в такой паралич часто быстрее разработчика. Проблема сложная и возможно заслуживает отдельного анализа и статьи. Может быть поделитесь другими сложностями, решение которых лично Вам было бы интересно?
У нас с этим попроще, но попробую предложить решения:
А если не секрет какая предметная область требует изучения нормативной документации по 9 месяцев?
В нашем случае (продуктовая разработка) получается для команды и заинтересованных лиц. Но и на практике внедрений и внешних проектов заказчики (не все конечно) готовы идти на компромиссы и отказываться от жесткого ТЗ.
Где как, но чаще архитекторы и аналитики, вы правы. Я имел ввиду именно проектную документацию (ТЗ, спецификации).
Сильно зависит от заказчика, но может работать. Коллега из отдела внедрения недавно писал статью по опыту недавних внедрений как раз по fixed price и time&material.
Конкретные проекты назвать не могу, предметная область — ЕСМ и все что вокруг ЕСМ.
Аналитик физически в команде, активно участвует в исследовании, проектировании, тестирует, занимается документацией и справкой. Задач по ходу спринта хватает для 100% загрузки.
Все в рамках проектирования в итерации. Если это будет отдельно, а потом отдельно проектирование, а потом отдельно реализация это уже не совсем Scrum :-)
Потому что это нужно для проектирования, чтобы понять полную картину. Конечно можно исследования проводить заранее, но на практике они устаревают и забываются к началу итерации, поэтому делаем все вместе.
Мы сейчас на выброс ничего не пишем, я собственно об этом и писал. Документируем необходимый минимум, в основном в виде мокапов.
А вообще «программисты пишут бумажки» это распространенная практика, особенно когда заказчик требует тщательно описать все в ТЗ, правда потом его сам не всегда читает.
Посмотрел по прошлому релизу: проектирование + разработка, тестирование и поддержка реализованного (баги, развертывание, продуктивы и т.д.) занимают одинаковое время.
Обучение внутри команды + самостоятельно по справке к продукту, парное программирование, своя wiki по архитектуре и приемам разработки, привлечение к проектированию и планированию.
Обычно этого достаточно, чтобы освоиться за пару месяцев.
Похоже на планирование, но:
Если говорить про остальных «заинтересованных лиц», то в любом случае придется потратить время на взаимодействие. Либо в виде демо, либо в виде постоянных ответов на их вопросы, потому что сами они могут неправильно понять что вы делаете и зачем.
А фишка в том, что взять методологию — это половина дела, надо еще адаптировать ее под себя. И я как раз scrum не пиарю, он в этом не нуждается, а просто делюсь наблюдениями за эти 5 лет.
Ничего против них не имею, но именно в концепции аналитика-проектировщика есть определенные минусы, которые в моем случае получилось устранить за счет проектирования всей командой.
Не поленился и нашел опрос, которой проводили как раз по итогам, на тему все ли устроило в бытовом плане. Вот типичные ответы:
Я с ними согласен, сам факт того, что все собрались и потратили свои выходные вместе — это круто. А остальное хотя и важно, но второстепенно.
Относительно бесплатных фич — не знаю финансовых подробностей организации хакатона, естественно была бесплатная еда, и за эти выходные нам в итоге заплатили как за рабочие дни. Для руководства наверное это хороший способ увидеть новые идеи и получить прототипы. Я не вижу в этом ничего плохого, в этой ситуации выигрывают обе стороны.
С учетом того, что полезной и реализуемой оказывается примерно 1 идея из 10 и на доведение ее до ума нужно времени в 10 раз больше, чем на прототип я бы поспорил с тем, что это «бесплатные фичи».
А главная разница между обычными рабочими днями и хакатоном в том, что мы были абсолютно самостоятельны в выборе темы, формата работы, команды и т.д. Собственно в тот момент я получал фан и не думал о том, что эту фичу мы потом прикрутим к продукту уже в обычное рабочее время.