Комментарии 30
Правда, заказчик от роли аналитика все равно отказался — не знаю, по каким причинам.
Вы же его сами предоставили бесплатно, он и понадеялся на дальнейшую халяву
Как вариант.
Мы делали это для того, чтобы наглядно показать заказчику разницу.
На словах не достучались, пришлось показывать действиями и цифрами.
Решение в любом случае принимать заказчику, нам главное донести ценность (в качестве исключения - продемонстрировать) и попытаться улучшить условия для нашей команды, потому что команда занимается не только своим делом.
И обычно цифры и результат дают хороший результат, но не в этом случае)
Какая животрепещущая лично для меня тема. К сожалению, за 7 лет в разработке встретилось всего пара аналитиков, которым по итогу работы хотелось пожать руку. Остальные по факту оказывались джунами-копирайтерами, которые только и могли что переносить мысль "делайте хорошо, плохо не делайте" из головы заказчика в задачу в джире.
Для себя выделил 3 критических пункта:
В разработке ПО нет слова "подразумевается". Подразумеваться могут только стандарты вроде использования HTTP в рестовой архитектуре. Поэтому в ТЗ должны быть даже те вещи, которые лично вам кажутся трижды очевидными. Разработчик не имеет (пока) доступа к вашему разуму.
Нужно обязательно хотя бы в общих чертах понимать архитектуру современных систем, модели и протоколы их взаимодействия. Иначе в ТЗ гарантированно будет оторванная от реальности дичь и испорченные отношения с инженерами
В статье сказано про "энциклопедию проекта" - а я добавлю, что еще необходим и глоссарий проекта. Одна и та же вещь в разных местах проекта должна называться одинаково. Это должно быть закреплено на самом верху и строго соблюдаться повсеместно.
Да, вы правы, в разных компаниях под роль аналитика зачастую закладываются разные обязанности. В одном месте аналитик - это тех.пис по факту, в другом - ребята которые пишут требования, а в третьем погружение вплоть до проектирования API и баз данных.
Молодых специалистов мы стараемся контролировать первое время и ревьюить их артефакты, чтобы требования соответствовали нашим критериям качества.
Спасибо за дополнения. Перечисленные критические пункты, действительно, правильные и первые два можно раскрыть подробнее в следующих статьях.
Про глоссарий в точку!
Хорошая статья, сам недавно проходил собеседование на вакансию аналитика, в крупной организаций, а так как должность тока появилась , директор сам точно не понимал чего хотел от аналитика, сводил всю суть работы на анализ ёмкости рынка и простой призентаций в мастер поинт.
Я же думаю аналитик должен знать всю цепочку создания стоимости, и работать на всех участках
Есть профессиональный стандарт "бизнес-аналитик" и есть "системный аналитик", полезно почитать, чтобы не порождать описания кентавров. Ну и чтобы ответственно заявлять, что вы по факту работаете за троих (за РП тоже ведь, наверное, ну чуточку... или за четверых?)
Конечно, есть профессиональный стандарт и определения «бизнес-аналитик», «системный аналитик», но много компаний работают именно с fullstack аналитиками. Мы пытались абстрагироваться от этих определений и использовать просто - аналитик.
Эта тема очень дискуссионная и у нас с обеих сторон найдется много аргументов, но такие «кентавры» работают и имеют право на жизнь.
Лучше ли такой подход? Я уверена, что нет (также как один frontend и один backend разработчики будут лучше одного fullstack). Но есть на то причины, видимо, если таких аналитиков достаточно много на данный момент.
И небольшой плюс - молодые специалисты могут на себе прочувствовать и понять, что им ближе по духу - быть fullstack аналитиком или развиваться в одном из направлений :)
Нужно больше заблуждений:
Стандартизация - зло - каждое решение должны быть уникальным
Не писать в ТЗ очевидные (для аналитика) по итогам общения вещи
ТЗ лишнее, если есть переписка в мессенджере
Формировать ТЗ под конкретного разработчика это правильно
> Но это не проблема заказчика — это проблема исполнителя.
Ну здрастити! Тогда заказчик будет вообще не переставая менять требования.
При возникновении такой ситуации говорим: "Мы, конечно, всё переделаем, как Вы хотите, но это обойдётся Вам в ХХХ тугриков". Очень хорошо отрезвляет и заставляет заказчика в будущем больше думать над формулированием своих требований.
Или ванговать "доработки" и сразу закладывать их в стоимость. Но риски остаются.
Причём очень большие, ибо предсказывают будущее люди ну оооочень плохо.
Немного вырвана фраза из контекста :)
Да, команде это может не понравиться:..
Но это не проблема заказчика — это проблема исполнителя.
То, что это не нравится команде - наша проблема. То, что меняются требования - это в принципе не проблема. Главное правильно обработать эти изменения.
Абсолютно согласна с вашими комментариями.
Мы предсказывать не можем, мы можем только выявлять и сегодня это работает так, а завтра что-то добавили (этого не было, но это окажет положительно влияние) / переделали.
И если это доработка, конечно, она проходит через фразу «Мы, конечно, всё переделаем, как Вы хотите, но это обойдётся Вам в ХХХ тугриков». Но! Перед этим аналитику стоит узнать что за изменение, для чего и какую проблему решит. И возможно его и оценивать команде не придется, потому что эта доработка ничего не дает и получится работа ради работы.
Дальше уже работа PM-а - провести это через бюджеты, запланировать в спринт и тд.
Значит, я неправильно понял, у меня после прочтения сложилось впечатление, что "изменение требований в процессе (или тем более после) разработки – это не проблема заказчика, а проблема исполнителя".
Был неправ, вспылил. Но теперь считаю своё предложение безобразной ошибкой, раскаиваюсь, прошу дать возможность загладить, искупить. Всё, ушел.
:)
Тогда заказчик будет вообще не переставая менять требования.Наш любимый заказчик (20 лет взаимодействуем) выдал как-то «Надо было делать не то, что написано в согласованном ТЗ, а то, что мы имели в виду».
«Мы, конечно, всё переделаем, как Вы хотите, но это обойдётся Вам в ХХХ тугриков». Очень хорошо отрезвляетЗамечательно. Заказчик тупо не заплатит. Или откажется вообще, или потом выкатит миллионную неустойку за неработоспособность, в договоре соответствующее примечание найдётся. Отрезвлять заказчика полезно, когда есть в запасе другой.
Короче говоря, нет здесь идеального решения «делай, как написано, и всё получится».
Но, всё же, предложу: нужно понимать заранее, что так будет, и в стоимость всех работ сразу закладывать расходы на доработки. А не радовать исходно заказчика низкой ценой.
Наш любимый заказчик (20 лет взаимодействуем) выдал как-то «Надо было делать не то, что написано в согласованном ТЗ, а то, что мы имели в виду».
Ну т.е. из-за того, что попадаются неадекватные заказчики (а они, конечно же, есть) Вы предлагаете всегда изменение требований постфактум считать проблемой исполнителя?
потом выкатит миллионную неустойку
Мы ведь говорим о требованиях, которые были заказчиком утверждены и подписаны, так? Поэтому юридически неа, он бессилен.
в стоимость всех работ сразу закладывать расходы на доработки
Как вариант – почему бы и нет? Но и в этом подходе есть минусы:
Из-за изначально более высоких цен теряем часть потенциальных заказчиков.
Т.к. речь идёт о предсказании будущего, мы будем регулярно промахиваться. И работать в таких ситуациях себе в убыток.
Ну т.е. из-за того, что попадаются неадекватные заказчики (а они, конечно же, есть)Заказчика, с которым успешно работаем двадцать лет, выполнили десятки проектов — считать неадекватным? Только из-за того, что Вы не поняли, что жизнь не укладывается в примитивные правила? Не-е-е, я не согласен.
Вы предлагаете всегда изменение требований постфактум считать проблемой исполнителя?Это де-факто так. И нужно это понимать до начала любых переговоров, включать в риски и учитывать в стоимости. Тупо накидывая проценты к каждому пункту сметы. Тогда и вы (мы) имеем, на что выполнять хотелки, и заказчик не будет считать нас (вас) капризными неумёхами.
Другое дело — продажа «изкаропки». Там что есть, то есть, никаких доработок и изменений цены.
Но и в этом подходе есть минусы:И на Солнце есть пятна
Из-за изначально более высоких цен теряем часть потенциальных заказчиков.Альтернативы просты: или обманывать заказчика, вымогая у него деньги сверх оговоренного, или работать забесплатно.
Т.к. речь идёт о предсказании будущего, мы будем регулярно промахиваться. И работать в таких ситуациях себе в убыток.Если Вы думаете, что увеличение стоимости после заключения договора создаст разработчику хорошую славу и приведёт новых заказчиков / новые договоры — Вы безудержный оптимист.
Рецепт «каша из топора» — одноразовый, второй раз не позовут готовить.
Дизайнеры получают подробно выявленные требования. Они понимают, для чего эта задача, какую проблему она закрывает, какие данные необходимы и как всё должно функционировать.
Без такого анализа дизайнер может не учесть скрытую логику или понять её некорректно.
Вот здесь непонятно. Если речь идёт про дизайнеров пользовательского интерфейса, то зачем им знать про данные и скрытую логику?
Может быть подразумеваются проектировщики ПО?
Если рассмотреть на примере:
Карточка товара. Чтобы ее отрисовать необходимо понимание, что в эту карточку вообще закладывается функционально и по данным (картинка, шильдики, название и тд).
Дизайнер отрисовывает дизайн по данным, которые собрал с карточки на сайте (это хорошо если есть сайт). Оказалось, что на некоторой обуви есть выбор ширины стопы (стандартная / узкая / широкая). Это нужно отразить в дизайне в нужном месте, а разработчикам отразить в приложении.
Также на дизайн влияет и формат данных - размерная таблица, например, картинкой или отдельными параметрами, которые нужно будет сверстать в таблицу. И такие нюансы нужно донести до дизайнера.
Когда аналитик ставит задачу - дизайнер знает, что есть ширина стопы и что размерная таблица параметрами, которые нужно свести в таблицу, например.
Опять же, в других компаниях могут отличаться процессы и обязанности, мы стараемся делать так, чтобы минимизировать доработки по всем фронтам.
Когда аналитик ставит задачу - дизайнер знает, что есть ширина стопы и что размерная таблица параметрами, которые нужно свести в таблицу, например.
Так вот и я о том, что это аналитик должен знать и учитывать скрытую логику, и вообще бизнес-логику и бизнес-данные. Это он знает, для чего эта задача, какую проблему закрывает и т.д.
Разработчики получают задание в уже очень рафинированном виде, им всё это знать совершенно не нужно. У разработчиков есть свой, огромный пласт знаний – внутреннее устройство системы, и аналитик нужен, в том числе, чтобы разработке не требовалось глубокое погружение в предметную область и бизнес-процессы. Иначе перегрузка и взрыв головного мозга :).
Вот здесь непонятно. Если речь идёт про дизайнеров пользовательского интерфейса, то зачем им знать про данные и скрытую логику?
Имхо, я вообще за то, чтоб дизайнер и аналитик был одним человеком. В идеале, чтоб "выгоревшие/уставшие" продуктовые дизайнеры с многолетним опытом шли именно в аналитики, а не в разработку (как советует каждая статья типа "дизайнер vs верстальщик").
Мне кажется, консолидация навыков дизайнера и аналитика в одной голове может дать крутой выхлоп. Фишка в том, что при словесном поносе заказчика сборе требований - он уже на подсознании будет мыслить экранами и пользовательскими сценариями.
При этом не обязательно ему также отрисовывать всё самому. Он может иметь джунов-дизайнеров в подчинении, или точечно отдавать на аутсорс рутину (правильно формулируя требования).
Вы правы.
Здесь акцент хотелось сделать на ТЗ, а когда оно состоит из верхнеуровневых требований следует много вопросов от команды, а уточнения тоже требуют времени.
В случае с джунами - мы стараемся их контролировать первое время и ревьюить их артефакты, чтобы требования соответствовали нашим критериям качества.
Выше достаточно неплохо на эту тему написали, что заказчик выдал «Надо было делать не то, что написано в согласованном ТЗ, а то, что мы имели в виду». И именно это всем и нужно. Причем зачастую избавиться от шелухи «требований» очень тяжело, поскольку требования подаются как непоколебимые.
И это кроме того, что в действительно хороших продуктах (а мы же все стремися стать крутыми специалистами?) нужно использовать лучшие, а не массовые решения, что вообще отдельный квест.
Кажется, статью стоит назвать "Топ заблуждений об аналитиках в Surf_studio". Ваши примеры очень частные и каждый из них может быть опровергнут.
Почему проектный менеджер не может опросить заказчика и выявить требования на достаточном уровне? Для этого не требуется каких-то сверхъестественных методик и можно сэкономить зарплату на аналитика.
Также - если заказчик самостоятельно внятно составил свои требования, которые понятны команде разработчиков, QA и дизайнеров, то зачем тратить деньги на аналитика?
Разработчики - это не операционисты для "написания кода". Они должны хотя бы поверхностно вникнуть в предметную область и куда глубже в объектную модель, в потоки данных и пр. и по итогу спроектировать решение. Они в любом случае будут анализировать требования и синтезировать решение. Аналитик в этом их не заменит.
Также - если заказчик самостоятельно внятно составил свои требования, которые понятны команде разработчиков, QA и дизайнеров, то зачем тратить деньги на аналитика?
А если младенец сам умеет готовить еду и гулять, то можно не тратить деньги на няню. Но увы. Часто вам такие заказчики попадались?
У меня есть опыт работы в команде без аналитика вообще. Жить-то, конечно, можно, но быстро приходим к тому, что аналитиком становится самый грамотный разработчик или QA. Естественно, без всяких доплат.
Есть внутренние заказчики, которые обладают необходимой экспертизой в предметной области, могут просмотреть аналоги решений, могут составить требования и обосновать их. И мало того, они еще спросят реализацию этих требований при приемочном тестировании и не примут работу, если вдруг кто-то решил их изменить.
Мне попадались внятные заказчики, я потому и ставлю под сомнение применение этих "заблуждений" на всех аналитиков.
Куча крутых продуктов создают команды грамотных специалистов без аналитиков. Я сам будучи аналитиком порой не понимаю, зачем меня принимают в команды, которые и так хорошо решают задачи. Приходится их покидать.
Сейчас роль аналитика трактуют настолько широко от команды к команде, что я пока прихожу к выводу, что так называемым "аналитиком" закрывают дыры в грамотности специалистов и заказчиков и коммуникациях между ними из-за низких требований, предъявляемых этим специалистам. И это не затрагивая деления на бизнес- и системных аналитиков - там вообще беда с пониманием.
Есть в ваших словах доля правды, от компании к компании роли и обязанности отличаются. И есть достаточно хорошие компании, в которых нет аналитиков вовсе и они выпускают качественные продукты.
Плюс к тому же это зависит еще и от сложности проекта. Без аналитиков сделать мобильный банк или систему для мониторинга, планирования и управления бизнес-процессами, я думаю, будет достаточно сложно - много нюансов.
Мы постарались ответить в статье на вопрос зачем тратить деньги на аналитика и, конечно, мнения могут расходиться. Не с пустого места же взялись эти заблуждения :) Эта тема сама по себе очень холеварная и мы часто слышим такие слова.
Если подытожить, то без аналитика работать можно, но без анализа нет, он так или иначе будет. Вопрос в том, кто и как будет этим заниматься.
А на замену разработчиков никто не претендует и, конечно, их участие на этапе проектирования необходимо и все перечисленные активности разработчиков никто не отменяет. Но у них в таком случае на порядок больше входных данных.
Топ-5 заблуждений в работе аналитика