Comments 12
Текст статьи не станет проще и интереснее, если вы будете втыкать мемы через абзац.
Если говорить, по существу. Проблема вашего представления постановки задачи в том, что оно императивное, то есть техническое решение известно еще на этапе постановки. В таком случае зачем вам вообще разработчики? Пишите сами, будет быстрее.
Разработчику не нужны ваши идеи, как и что использовать на техническом уровне — это его прямой интерес и зона ответственности. Не говоря уже о том, что вы можете предлагать просто сложные и ошибочные решения, технических навыков то у вас нет.
В этом плане ваши примеры "хорошо описанных задач" просто ужасны. Ни в одном из примеров не описано, кому вообще нужны эти фичи, в каком контексте и какая польза бизнесу, зато полно сомнительных технических деталей.
На практике, взаимодействие аналитиков и исполнителей часто деградирует до такого императивного описания, потому что аналитик, уставший от вопросов разработчиков, замечает, что вопросов становится меньше, когда он буквально описывает расположение кнопок и название переменных — это жиза.
На самом деле проблема в том, что проектный менеджер не выдаёт качественный анализ предметной области, сам не знает чего хочет бизнес.
Для правильной постановки задачи нужно исчерпывающее описание и бизнес аналитика предметной области: кто действующая роль, позитивные и негативные сценарии, ограничения и допущения. Разработчик, если нет соответствующей роли, сам проведет системный анализ и выдаст вам классные варианты решения задачи с оценками.
Текст статьи не станет проще и интереснее, если вы будете втыкать мемы через абзац.
Ну это вкусовщина и кому как.
техническое решение известно еще на этапе постановки
Не очень понимаю где тут техническое решение. Удобное предоставление информации по взаимодействию с API и данными это техническое решение? Описание кейсов – это бизнес-логика, которая должна соответствовать поставленным требованиям и те же 0-даты не могут отдаваться на усмотрение разработчика. Разработчики, в моем представлении, не должны придумывать как решать проблему бизнеса, не должны пытаться выяснять требования, они должны решать технические вопросы, писать красивый и качественный код с минимальным числом ошибок и переделок. А для этого следует давать им необходимую информацию. Также описание необходимо и для тестирования, для понимания логики взаимодействия с сервером. Поясню, что мы занимаемся аутсорс разработкой и требования к моменту передачи фичи в разработку уже довольно определены. А наши менеджеры прекрасно разбираются в своей области и часть связанную с проектированием API закрывают самостоятельно или при помощи разработчиков до непосредственного начала выполнения задачи, так как нам важно не быть заблокированными в процессе бэкендом.
В этом плане ваши примеры “хорошо описанных задач” просто ужасны. Ни в одном из примеров не описано, кому вообще нужны эти фичи, в каком контексте и какая польза бизнесу, зато полно сомнительных технических деталей.
Кажется, что разработчикам не особо надо пояснять зачем нужна загрузка данных или для чего нужен неавторизованный стейт экрана. При этом про важность информации для чего фича нужна, если это не очевидно, в тексте статьи написано. Наши разработчики любят предлагать фичи и улучшать пользовательский опыт, но это делается через обсуждения и согласования, а не отдается им на единоличное решение. И задачи из разряда “Сделай экран хорошо” без описания мы не делаем.
В чужой монастырь лезть не буду. Если вас и ваших разработчиков всё устраивает, могу искренне только порадоваться. Никаких претензий.
Однако вы публикуете статью, которая оформлена как руководство к действию. Этим могут воспользоваться другие менеджеры. Поэтому на правах дискуссии я всё же отвечу на ваши вопросы, чтобы плохие практики не уходили в массы без обсуждения.
TL;DR Каждый должен заниматься своим делом. Выбор технического решения и проектирование API — не дело менеджеров.
Не очень понимаю где тут техническое решение. Удобное предоставление информации по взаимодействию с API и данными это техническое решение?
Интересно что придумывание API вы не считаете техническим решением. В любом случае это не удобное представление. Сейчас можно сказать стандартом является спецификация OpenAPI или аналоги, которую можно использовать не только для описания API, но и для автоматизации разных процессов разработки.
Может быть, вам всё это не нужно, но приводя в пример такие приколы, некоторые подрядчики будут и дальше считать, что нормально присылать на интеграцию API в Word файлах вот с такой вот отсебятиной:
Запрос - POST {baseUrl города}/user/password
Передаём: { “email”: “введённый юзером имейл” } И да, указание, когда начинать загрузку, до скрола или нет, как представлять параметры запросов в API — всё это техническое решение.
Хорошо если ваши проектные менеджеры настолько компетентны в техническом плане. Но они в любом случае не видят устройство системы изнутри, а значит могут ошибиться. Если ваши разработчики никогда не жалуются на технические решения менеджеров, может быть, они всё делают на пофиг. Не задумывались над этим?
Разработчики, в моем представлении, не должны придумывать как решать проблему бизнеса, не должны пытаться выяснять требования, они должны решать технические вопросы, писать красивый и качественный код с минимальным числом ошибок и переделок. А для этого следует давать им необходимую информацию.
В общем смысле не должны. А проектные менеджеры и бизнес аналитики не должны решать технические задачи за разработчиков. Чтобы получался качественный код с минимальным числом ошибок и переделок не нужно API за разработчиков писать и кнопки на макетах расставлять. Нужно предоставлять наиболее полное описание сценариев, особенно негативных, особенно с перспективой на развитие бизнеса. Тогда технический анализ и прогноз разработчика будет более точный, а значит и решение более качественное.
Кажется, что разработчикам не особо надо пояснять зачем нужна загрузка данных или для чего нужен неавторизованный стейт экрана.
Вот в этом и проблема. Если говорить про неавторизованный стейт экрана:
А анонимный и неавторизованный пользователь это одно и то же?
А если неавторизованный стейт предполагает демо режим приложения?
А если его потом нужно конвертировать в авторизованного?
А что, если нужно переносить неавторизованный стейт между разными устройствами?
Если вместо ответа на эти и подобные вопросы вы указываете разработчику, где кнопку разместить, то не удивляйтесь потом что разработанное решение невозможно адаптировать под ваши новые хотелки.
Короче говоря, моя мысль в том, что, указывая разработчикам техническое решение, вместо предоставления качественной аналитики и проектирования по задаче, вы блокируете возможность выбрать наиболее эффективное решение не сейчас, так в будущем.
Поясню, что мы занимаемся аутсорс разработкой и требования к моменту передачи фичи в разработку уже довольно определены.
И это хорошее замечание. Для качественной продуктовой разработки ваши примеры неуместны.
В любом случае, кроме примеров, в вашей статье есть дельные соображения, спасибо.
Да, конечно, все зависит от компании. И возможно, что где-то этими задачами будет заниматься не один проджект-менеджер, как у нас, а еще будет бизнес-аналитик, системный-аналитик, тимлид, архитектор и другие роли. Хотелось больше подсказать вещи, которые помогают ошибаться меньше, даже если они будут распределены.
Про такое описание API – не всегда мы от команды бэкенда заказчика получаем красивый сваггер на который можно сослаться (как всегда хочется), в итоге иногда приходится выяснять разными доступными способами и запросы, и ответы, и опциональность и прочее. Если есть возможность сослаться на спеку по запросу, то отлично, но это только один пункт из работы по задаче)
В любом случае, кроме примеров, в вашей статье есть дельные соображения, спасибо.
Надеюсь)
Прочитал статью, выглядит так, что работники какие-то бездумные машины, конвеер которых должен обрабатывать входящие задачи из таск трекера - "так не-ра-бо-та-ет", точнее работает но плохо и со скрипом иначе бы не было статьи.
Разработчик, не кодер это прежде всего разумное(внимание! разумное) существо, которое способно не решить задачу, а решить проблему. И в этом принципиальная разница.
Опишу на примере одной задачи
Заголовок: сделать восстановление пароля
Текст: пользователь может логиниться через форму, "один", "два" и "три". <тут далее добавить продуктовые детали>.
Юзер вполне может захотет восстановить пароль из профиля ибо тот сохранен, а он не знает как просмотреть содержимое например.
Далее в зависимости от того как устроен процесс, задача вешается на разработчика, тот обговаривает решение с лидом, ибо лид отвечает за техническое решение и они делают.
какие запросы куда идут - вообще без разницы, за это отвечает либо лид, либо архитектор, либо тот кто видит целостную картину.
Далее разработчик может для себя разбить на подзадачи. Как только есть что показать, он выдергивает кого-то с клиентской стороны и говорит и говорит люди мы сделали восстановление пароля, давайте на своих там тестайте. Как это происходит не суть важно, важно чтобы со стороны клиента был человек, который ждет этой фичи.
В разработке главное люди: "нельзя заменить одного человека другим, как винт в механизме"
по этому вся вышеприведенная статья это как облегчить геморрой, но не избежать его или вылечить.
P.S. и еще бросилось в глаза: "Устные договоренности ничего не значат!" - брехня. Может звучит грубо, но:"за базар надо отвечать", потому что люди за него помнят и могут спросить.
И прежде всего этой аксиоме должен следовать руководитель - его слово куда весомее его подчиненных
В целом по всем вопросам уже отвечала в комментарии выше, но:
какие запросы куда идут - вообще без разницы, за это отвечает либо лид, либо архитектор, либо тот кто видит целостную картину.
У нас менеджер и видит целостную картину. В зависимости от размера команды появляются новые роли, для которых так или иначе написанное в статье актуально. Можете это воспринимать как текст для разработчика и то, что ему нужно учесть при работе над задачей
Спасибо за статью, было познавательно узнать практический опыт - как работают с требованиями в разных компаниях.
Очень заинтересовал вопрос "менеджеров" - кто эти люди. У нас на проектах эти функции выполняют обычно 3 разных человека (иногда два, но чаще три). Кажется что нужно иметь много разных компетенций, чтобы делать всё это сразу с достаточным качеством.
Можете рассказать - какой у менеджеров обычно бекграунд, легко ли их нанимать, есть ли какая-то программа подготовки (курс молодого бойца)?
Приходящие менеджеры с опытом в других айти-проектах обычно, но обычно не настолько глубоко погруженные в тех. часть. У нас плавный онбординг и обучение всему необходимому под контролем более опытного менеджера. Поэтому при найме супер завышенных требований нет, скорее выделяем достаточно времени на обучение внутри, например, той же самой работе с API. Но проблем не возникает
Если в описании согласования ТЗ на разработку программы нет:
- графов переходов,
- таблиц решений,
- конечных автоматов ...
в общем, проверенных инструментов согласования понимания и корректировок между заказчиком и разработчиком, автора ждут интересные и полезные открытия.
Проблем согласований с заказчиком у нас нет, спасибо) Как нет и проблем недопонимания менеджеров и разработчиков. Про данные инструменты знаем, они применяются на тех задачах, где необходимы, а каждую задачу снабжать бесконечным числом артефактов не стоит. Помним про условие необходимости. И как написано в статье добавлять любые визуальные и информационные артефакты можно, если они помогут в лучшем понимании информации
Где-то проскакивала такая идея: разработка это творчество, а творчеству нужно ставить цели а не ограничения, как их достичь оно найдет само.
Суть в том, что у разработчика множество инструментов для достижения цели: он взаимодействует непосредственно с кодом и всеми его особенностями, большинство из которых нигде не описаны, и поэтому не могут использоваться для проектирования кем-то кроме разработчика, также он имеет какой-то индивидуальный опыт и знания, которые могут выстрелить и серьезно сократить/упростить/ускорить/улучшить код, и опять же никто кроме разработчика такое предусмотреть не в состоянии. Творчество как оно есть.
Так что в идеале просто требуется максимально наглядно донести до разработчика конечный результат. Для фронта - макеты и описание/скриншоты состояний. Для бека - диаграммы, дающие понимание что должно происходить в системе на высоких уровнях.
В реальности же в крупных фирмах многие разработчики - многостаночники: они не погружены в конкретный проект. Обычно есть ведущий разработчик, ответственный за проект, имеющий с ним много опыта, и "мускулы" - разработчики, которых привлекают по потребности к разным проектам, нередко сразу к нескольким. Так что у большинства из них нет никакой информации о проекте, кроме той, что есть в задаче и в описании проекта. Именно поэтому в задаче важно описать все так, чтобы было понятно новичку: разработчик придет с другого проекта на поддержку, он не знает какие механики есть на проекте и как интерпретировать скудное ТЗ, у него нет контекста. Есть конечно ведущий разработчик, и он частично это может компенсировать, но только частично: если все так плохо огганизовано, ему придется и за аналитика и за продакта работать. Разовый затуп он может разгрести, но если на постоянку так - просто уволится. Поэтому все это должно быть организовано заранее.
Но чтобы реализовать этот творческий потенциал, разработчики должны привлекаться к процессу проработки ТЗ на уровне технических консультантов.
Да, все так. Именно поэтому мы стараемся вовлекать разработчиков на всех этапах проекта. И на всех этапах получаем ценные идеи, которые с радостью передаем заказчикам, а те их очень часто согласовывают в работу. Не всегда разработчик, который на этапе ТЗ и проектирования помогает проведением технического-ревью, будет сам реализовывать задачу, поэтому в течение проекта также все разработчики вовлекаются на планированиях, демо и прочих митингах в бизнесовую часть, чтобы понимать что и для чего они реализовывают и могли предлагать идеи для улучшения проекта
Как правильно поставить задачу для разработки