Как стать автором
Обновить

Требования, еще требования, а какое стоп-слово? Работа системного аналитика с требованиями на разных этапах проекта

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров2.8K
Всего голосов 15: ↑14 и ↓1+17
Комментарии14

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

Коллеги немного поспорили, но согласились на первый вариант. Уж очень хотелось увидеть что получилось. А мы начали готовиться к новой доработке и новым требованиям.

Видимо, заказчику остро не хватает прототипа для пощупать, а не ждать всего этого

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

Есть такое. Для объемных доработок это особенно актуально, но к сожалению, в команде нет ресурса на разработку прототипов.

Зато есть ресурсы на почти полную переработку практически законченного решения? Мне кажется, извините, что это самообман. Возможно самообман у вашего заказчика.

Вообще прототип в большинстве случаев можно накидать из квадратиков и кружочков прямо поверх существующих макетов или даже скриншотов и это дело 1-2 дней. И заказчику сразу все становится гораздо понятнее. Это из личного опыта аналитики всяких абстрактных и сложных для восприятия API Gateway или генераторов DVB таблиц

Любая доработка выполняется по методологии Agile, и пока она дойдет до этапа системного анализа требования могут круто поменяться.

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

Клавиатуры целы, антидепрессанты не тронуты, заказчик доволен.

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

А какое стоп-слово в вашей команде?

Нет никаких стоп-слов, да и не должно быть. Есть (должно быть) совместное планирование спринтов – с учётом как потребностей заказчика, так и возможностей исполнителя. И очень похоже, у вас этот процесс либо отсутствует, либо не настроен должным образом.

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

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

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

Понимаете, при наличии выстроенных стандартных процессов такой кейс попросту невозможен. Особенно если заказчик внутренний и работает по тем же внутренним стандартам.

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

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

Этот "труаджаил" не работает. Вы им прикрываете себе задницу, чтобы заказчику говорить в ходе итерации "ну вот мы ж договорились, что делаем так вот на этой итерации".

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

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

Не говорю что не надо методологию применять какую-то. Но блин... В книгах любых нормальных по методологиям пишется "не надо слепо применять описанное. Надо адаптировать под свои задачи/работу, если уже процесс рабочий есть". И соответственно когда кто-то говорит "у нас аджайл" - не стоит сразу нападать с фанатизмом "а вот труаджайл..".

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

Разница в длительности этой итерации - когда заказчик увидит то, о чем договаривались ранее - через две недели или через два месяца. За два месяца он много чего понапридумывать может, и всё срочное.

Этот "труаджаил" не работает.

У меня работает, уже 20+ лет как. "Клавиатуры целы, антидепрессанты не тронуты, заказчик доволен. ©" Видимо, тот эджайл, который используете Вы, таки не вполне труЪ.

В книгах любых нормальных по методологиям пишется "не надо слепо применять описанное. Надо адаптировать под свои задачи/раработу

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

Раб аналитик, стоп слово...

Business Development Sales & Marketing

А то такая петрушка часто возникает, может, имеет смысл:

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

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

Сработает такой вариант? Кто на опыте, подскажите, пожалуйста.

Думаю, что опытные коллеги тоже выскажут свое мнение. А пока я напишу свое.

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

Живой приятный текст читается на одном дыхании 🔥

Зарегистрируйтесь на Хабре, чтобы оставить комментарий