Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 44
а) на фазе обсуждения бизнес идеи аналитик может подсказать:
— возможна ли реализация,
— способы и стоимость реализации.
«Но как, Холмс»?
Нам нужна система, которая будет обрабатывать сигналы о местоположении от 200+ тысяч пользователей и показывать их на карте с задержкой не более двух минут. Возможность, способы, стоимость?
Добрый день!
Отвечу на Ваш первый вопрос на основании личного опыта. Сталкивалась с 2-мя ситуациями:
1. Аналитик работает с системой, где требуются изменения (самая простая ситуация). Как правило, тут человек уже через несколько месяцев работы неплохо знает и предметную область, и возможности программистов, и архитектуру системы. Или знает, где подсмотреть, кого спросить. Может рассказать, что вот для этого изменения нужно доработать логику, для этого — менять архитектуру, но можно сделать что-то проще, но без изменений архитектуры, и т.п. По опыту знаю, что аналитик довольно быстро учится делать достаточно точные оценки в такой ситуации, если часто практикуется:)
2. Нужно сделать оценку для кардинально новой разработки. Аналитик изучает предметную область, советуется со специалистами, и после проделанной работы предлагает варианты заказчику. Учитывается множество факторов, возможные технологии. Что быстро сделать под iOS, под андроид сложнее, и наоборот :)
По поводу вашего второго вопроса: сходу не скажу, надо исследовать :) какая карта, платные или бесплатные возможности популярных карт? Какой сервер, какой канал, какая нагрузка? Пообщавшись с заказчиком и с экспертами, аналитик вам предложит варианты.
Отвечу на Ваш первый вопрос на основании личного опыта. Сталкивалась с 2-мя ситуациями:
1. Аналитик работает с системой, где требуются изменения (самая простая ситуация). Как правило, тут человек уже через несколько месяцев работы неплохо знает и предметную область, и возможности программистов, и архитектуру системы. Или знает, где подсмотреть, кого спросить. Может рассказать, что вот для этого изменения нужно доработать логику, для этого — менять архитектуру, но можно сделать что-то проще, но без изменений архитектуры, и т.п. По опыту знаю, что аналитик довольно быстро учится делать достаточно точные оценки в такой ситуации, если часто практикуется:)
2. Нужно сделать оценку для кардинально новой разработки. Аналитик изучает предметную область, советуется со специалистами, и после проделанной работы предлагает варианты заказчику. Учитывается множество факторов, возможные технологии. Что быстро сделать под iOS, под андроид сложнее, и наоборот :)
По поводу вашего второго вопроса: сходу не скажу, надо исследовать :) какая карта, платные или бесплатные возможности популярных карт? Какой сервер, какой канал, какая нагрузка? Пообщавшись с заказчиком и с экспертами, аналитик вам предложит варианты.
Может рассказать, что вот для этого изменения нужно доработать логику, для этого — менять архитектуру, но можно сделать что-то проще, но без изменений архитектуры, и т.п.
На основании чего аналитик принимает решения, для чего нужно менять архитектуру, а для чего — нет, и какое изменение архитектуры «проще» или «сложнее»? Какую роль в команде играет архитектор?
Аналитик изучает предметную область, советуется со специалистами, и после проделанной работы предлагает варианты заказчику.
Так аналитик может подсказать, или аналитик может посоветоваться со специалистами и транслировать их мнение?
какая карта, платные или бесплатные возможности популярных карт? Какой сервер, какой канал, какая нагрузка?
Нагрузка озвучена, все остальное на ваше усмотрение. Интересуют возможные варианты с их плюсами/минусами и стоимостью.
Решения принимает на основании анализа системы (как ни банально это прозвучит), знаний и опыта. Бывают случаи (часто!), когда аналитик выполняет функцию архитектора. В разных проектах разное распределение ролей.
По поводу подсказать или транслировать: оба варианта имеют место быть. Глупо злоупотреблять опытом гуру. Иногда нужно собрать их мнение и транслировать заказчику, это тоже работа аналитика, он выступает звеном между заказчиками и разработчиками.
На счёт оценки системы: не могу сходу ответить. Оценка возможностей системы, существующих решений, уровня программистов и т.д. может занимать достаточно долгое время.
По поводу подсказать или транслировать: оба варианта имеют место быть. Глупо злоупотреблять опытом гуру. Иногда нужно собрать их мнение и транслировать заказчику, это тоже работа аналитика, он выступает звеном между заказчиками и разработчиками.
На счёт оценки системы: не могу сходу ответить. Оценка возможностей системы, существующих решений, уровня программистов и т.д. может занимать достаточно долгое время.
Решения принимает на основании анализа системы (как ни банально это прозвучит), знаний и опыта.
Откуда у аналитика (особенно — бизнес-аналитика) опыт, скажем, в проектировании (ну там — протоколы, партиционирование, вся эта требуха) распределенных систем с совместной работой?
Бывают случаи (часто!), когда аналитик выполняет функцию архитектора.
Я могу еще поверить в обратное (когда человек с основной ролью архитектора еще и выполняет роль аналитика); но надо понимать, в любом случае, что роли аналитика и архитектора фундаментально различны.
На счёт оценки системы: не могу сходу ответить. Оценка возможностей системы, существующих решений, уровня программистов и т.д. может занимать достаточно долгое время.
Это, извините, уже этап анализа. А вы написали, что аналитик может это подсказать на этапе обсуждения бизнес-идеи.
А откуда вообще берется опыт? (Риторический вопрос). Аналитику в принципе нужно много знать и уметь. Мне приходилось работать в компаниях, где роли аналитика и архитектора были совмещены. И знаю, что не только в тех компаниях так было.
На этап обсуждения бизнес-идеи уважающий себя аналитик приходит подготовленный. А если знания, опыта не хватает, чтоб сходу посоветовать, то не зазорно взять время и провести дополнительный анализ.
На этап обсуждения бизнес-идеи уважающий себя аналитик приходит подготовленный. А если знания, опыта не хватает, чтоб сходу посоветовать, то не зазорно взять время и провести дополнительный анализ.
А откуда вообще берется опыт? Аналитику в принципе нужно много знать и уметь.
Опыт берется из образования и проведенной работы. Надо просто помнить, что в голову к каждому человеку влезает не так много опыта, а работа аналитика сама по себе достаточно сложна, чтобы требовать full-time dedication.
Сколько книг по архитектуре ПО лично вы прочитали?
Книг достаточно прочитала, да и до аналитики немного работала в разработке и проектировании.
Но я Вас понимаю, лучше, когда есть и архитектор, и аналитик.
А вот на практике бывает иначе. В двух компаниях из четырех от меня требовали заниматься проектированием. Пришлось разбираться. И сейчас мне кажется, что даже хорошо, когда аналитик в состоянии копнуть немного глубже.
Но я Вас понимаю, лучше, когда есть и архитектор, и аналитик.
А вот на практике бывает иначе. В двух компаниях из четырех от меня требовали заниматься проектированием. Пришлось разбираться. И сейчас мне кажется, что даже хорошо, когда аналитик в состоянии копнуть немного глубже.
А как вы разграничиваете роли аналитика, архитектора и проектировщика? Мне, честно говоря, тоже странно выполнение одним человеком ролей архитектора и аналитика одновременно. Я бы в этом случае предположил, что этот же человек и основной разработчик тоже.
(достаточно? назовете хотя бы пару названий?)
Понимаете ли, я за свои сколько-то лет работы в отрасли не видел ни одного бизнес-аналитика, способного (а системных аналитиков не видел вообще ни одного живьем):
Понимаете ли, я за свои сколько-то лет работы в отрасли не видел ни одного бизнес-аналитика, способного (а системных аналитиков не видел вообще ни одного живьем):
- выбрать между реляционным и нереляционным хранилищем (и аргументировать свой выбор)
- определить, строгая или отложенная (eventual) консистентность нужна в системе
- правильно оценить срок интеграции учетной системы с системой документооборота (причем обе уже используются в компании несколько лет)
А мне вот доводилось таких встречать.
Зачем им тогда архитекторы в команде?
Перечитываю комментарии, работая над продолжением статьи. Ниже в комментариях вроде разобрались, что я имела в виду, что аналитик, в основном, не заменяет архитектора, а чуть-чуть разбирается в архитектуре (на уровне, который необходим для подготовки качественных требований и разговора с программистами на близком языке: ER-модель, знание модели данных и понимание организации интеграции между системами, или что такие-то Api используют и возвращают такие-то параметры, etc).
Хотя мне действительно везло на команды, где аналитик выступал в роли архитектора, но это ведь не эталон, а просто специфика.
Смутившую вас фразу:
«а) на фазе обсуждения бизнес идеи аналитик может подсказать:
— возможна ли реализация,
— способы и стоимость реализации.» надо будет заменить на «участвует в обсуждении бизнес идеи и оценке». Ибо, хоть мне и приходилось во всех проектах собирать команду и заниматься оценкой, но это было пересечение с ролью ПМ, что тоже специфика, а не эталон :-)
Хотя мне действительно везло на команды, где аналитик выступал в роли архитектора, но это ведь не эталон, а просто специфика.
Смутившую вас фразу:
«а) на фазе обсуждения бизнес идеи аналитик может подсказать:
— возможна ли реализация,
— способы и стоимость реализации.» надо будет заменить на «участвует в обсуждении бизнес идеи и оценке». Ибо, хоть мне и приходилось во всех проектах собирать команду и заниматься оценкой, но это было пересечение с ролью ПМ, что тоже специфика, а не эталон :-)
Я как аналитик, могу смело сказать — по тонкому льду идете Елена, с таким подходом.
Из моего опыта, такие решения мы принимаем командно, с привлечением и бизнеса и разработки. Причем, часто, предлагаемое изначально решение, в ходе дискуссии может сильно трансформироваться
Из моего опыта, такие решения мы принимаем командно, с привлечением и бизнеса и разработки. Причем, часто, предлагаемое изначально решение, в ходе дискуссии может сильно трансформироваться
Я интересовался ай-ти всю свою жизнь и начал программировать в детстве на вижуал Бейсике на украденном папой с работы компьютером в 10 лет. Потом в университете 4 года в веб тим пока получал BS, год в Микрософте на C++ перед окончательным уходом в консалтинг. MS CS топовой школы, полтора десятилетия работы программистом с множеством крупных и мелких клиентов, десяток стартапов долины. Web Developer => Sr Web Developer => Engineer => Full Stack => Team Lead => VP of Engineering => Architect.
Абсолютно не ради хвастовства, просто мне действительно интересно, каким образом вы можете делать ту работу к которой я шёл всю свою жизнь a именно решать что и как сделать и за сколько денег? Каким образом у вас может быть достаточно квалификации что бы предложить решение данной задачи «система, которая будет обрабатывать сигналы о местоположении от 200+ тысяч пользователей и показывать их на карте с задержкой не более двух минут.» Откуда вы знаете producer–consumer паттерн, дизайн API, решениями для big data и различием между способами хранения/аналитики этой даты?
Абсолютно не ради хвастовства, просто мне действительно интересно, каким образом вы можете делать ту работу к которой я шёл всю свою жизнь a именно решать что и как сделать и за сколько денег? Каким образом у вас может быть достаточно квалификации что бы предложить решение данной задачи «система, которая будет обрабатывать сигналы о местоположении от 200+ тысяч пользователей и показывать их на карте с задержкой не более двух минут.» Откуда вы знаете producer–consumer паттерн, дизайн API, решениями для big data и различием между способами хранения/аналитики этой даты?
Ну а решение задачи выше может быть таким:
1. producer–consumer ( т.е. устройства пишут локально координаты с таймстемпом и шагом скажем 10 секунд и синхронизируются с сервером в бекграунде когда интернет есть и загрузка небольшая { device_id, lat, long, timestamp } )
2. К чёрту API, JSON и рукопожатия. UDP наше всё. Whatsapp таким образом миллионы(!) коннекшинов держит на одном сервере.
3. Elasticsearch для последних координат устройств ( и удобного гео-поиска с фильтрами ) и Cassandra для хранения всей истории перемещения ради последующей аналитики.
4. Ну допустим AWS
5. Google Maps For Work — $10K за год, Yandex ~ $6K. Покрытие Yandex в России хорошее а по миру не очень. OpenStreetMap бесплатно но из за ограничений по лимитам фиг сработает для 200К пользователей.
1. producer–consumer ( т.е. устройства пишут локально координаты с таймстемпом и шагом скажем 10 секунд и синхронизируются с сервером в бекграунде когда интернет есть и загрузка небольшая { device_id, lat, long, timestamp } )
2. К чёрту API, JSON и рукопожатия. UDP наше всё. Whatsapp таким образом миллионы(!) коннекшинов держит на одном сервере.
3. Elasticsearch для последних координат устройств ( и удобного гео-поиска с фильтрами ) и Cassandra для хранения всей истории перемещения ради последующей аналитики.
4. Ну допустим AWS
5. Google Maps For Work — $10K за год, Yandex ~ $6K. Покрытие Yandex в России хорошее а по миру не очень. OpenStreetMap бесплатно но из за ограничений по лимитам фиг сработает для 200К пользователей.
Поддерживаю.
Оценки сроков от аналитика одна из частых причин срывов сроков в проекте. Когда стал работать с «русским бизнесом» был неприятно удивлен распространенности этого явления. Хуже разве что архитектура от аналитика.
Здесь опыт нужен, чтобы в беседе с заказчиком определять проблемные места и подробнее доносить их до команды разработчиков. Тогда на встрече с разработчиками будет что обсудить: количество пользователей, лаг на карте, зачем нам все это нужно и какая у нас конечная цель, каковы критерии успеха. А не просто стоять человеком-телефоном и недоумевать.
Главное обходить 2 крайности:
— Заказчик часто озвучивает не функциональные требования, а свои представления о том, как это требование будет реализовано. Нужно уметь определить само требование.
— Заказчик лучше аналитика знает что ему нужно. Не стоит мнить себя мега-экспертом и делать «как лучше». Нужно делать как просят.
Оценки сроков от аналитика одна из частых причин срывов сроков в проекте. Когда стал работать с «русским бизнесом» был неприятно удивлен распространенности этого явления. Хуже разве что архитектура от аналитика.
Здесь опыт нужен, чтобы в беседе с заказчиком определять проблемные места и подробнее доносить их до команды разработчиков. Тогда на встрече с разработчиками будет что обсудить: количество пользователей, лаг на карте, зачем нам все это нужно и какая у нас конечная цель, каковы критерии успеха. А не просто стоять человеком-телефоном и недоумевать.
Главное обходить 2 крайности:
— Заказчик часто озвучивает не функциональные требования, а свои представления о том, как это требование будет реализовано. Нужно уметь определить само требование.
— Заказчик лучше аналитика знает что ему нужно. Не стоит мнить себя мега-экспертом и делать «как лучше». Нужно делать как просят.
Именно поэтому работа аналитика именно то что и подразумевает «бизнес аналитика» а именно формулировка задачи в более менее конкретных терминах ( например user stories или SRS ). Т.е. задачей аналитика как раз является встречи с клиентом в результате которого появляется формулировка «нужна система, которая будет обрабатывать сигналы о местоположении от 200+ тысяч пользователей и показывать их на карте с задержкой не более двух минут.» а ещё лучше подробности которые описанные в виде формального документа ( «нужна система ( что именно? код с установкой? поддержка? какие языки? какие версии контроля? ), которая будет обрабатывать сигналы (какие устройства? какие страны? ) о местоположении от 200+ тысяч ( с прицелом на будущее или нет ?) пользователей и показывать ( как показывать? веб? мобильные эппы? ) их на карте с задержкой не более двух минут.»
Т.е. идеальной работой аналитика является составление идеального документа который описывает задачу как можно подробнее. Именно саму задачу а не способы её решения. И цена, сроки, построение команды и архитектура это уже совсем другая квалификация и опыт.
Т.е. идеальной работой аналитика является составление идеального документа который описывает задачу как можно подробнее. Именно саму задачу а не способы её решения. И цена, сроки, построение команды и архитектура это уже совсем другая квалификация и опыт.
Спасибо!
Каждый должен заниматься своим делом, и делать его хорошо, согласна.
Просто нет стандартной должностной инструкции аналитика. В зависимости от компании, от проекта, требования к такой роли варьируются. Часто происходит совмещение: аналитик+ПМ.
Где-то аналитик занимается только функциональными требованиями, где-то — проектирует БД, составляет use cases (в том числе и вызов нужных API на соответствующих шагах сценария), моделирует прототипы пользовательского интерфейса, описывает правила интеграции систем.
Каждый должен заниматься своим делом, и делать его хорошо, согласна.
Просто нет стандартной должностной инструкции аналитика. В зависимости от компании, от проекта, требования к такой роли варьируются. Часто происходит совмещение: аналитик+ПМ.
Где-то аналитик занимается только функциональными требованиями, где-то — проектирует БД, составляет use cases (в том числе и вызов нужных API на соответствующих шагах сценария), моделирует прототипы пользовательского интерфейса, описывает правила интеграции систем.
Я считаю что да. Т.е. бизнес аналитика это именно общение с клиентом и перевод этого общения в формальные требования для разработки. PM тоже довольно часто ОК — в небольших компаниях это часто может делать один человек.
А вот архитектура/UX/DB это совсем не ОК. Без обид, но мнение разработчика ( если нет архитектора или тим лида ) тут более весомое чем ваше. Потому что более квалифицированное, конкретного опыта больше.
PM/Аналитик это медсёстра. Они должны померять температуру, распросить пациента и написать в карточку симптомы болезни, успокоить больного и сказать что всё будет хорошо. Разработчики это врачи ( каждый со своей специализацией, кто-то фронтэнд, кто-то бэкенд, кто-то выбирает мобильную разработку ), тим лид это заведующий отделом а архитектор это глав-врач. У каждого своя роль и свой необходимый уровень квалификации. Представляете что бы было если бы медсестра составляла план лечения сложных пациентов? Вы бы хотели бы лечится в такой больнице? :)
А вот архитектура/UX/DB это совсем не ОК. Без обид, но мнение разработчика ( если нет архитектора или тим лида ) тут более весомое чем ваше. Потому что более квалифицированное, конкретного опыта больше.
PM/Аналитик это медсёстра. Они должны померять температуру, распросить пациента и написать в карточку симптомы болезни, успокоить больного и сказать что всё будет хорошо. Разработчики это врачи ( каждый со своей специализацией, кто-то фронтэнд, кто-то бэкенд, кто-то выбирает мобильную разработку ), тим лид это заведующий отделом а архитектор это глав-врач. У каждого своя роль и свой необходимый уровень квалификации. Представляете что бы было если бы медсестра составляла план лечения сложных пациентов? Вы бы хотели бы лечится в такой больнице? :)
Еще раз повторюсь:)
Мнением архитектора и других специалистов никто не злоупотребляет.
Но, всё же, вы недооцениваете труд и знания аналитиков:) Тот же Вигерс (классика по требованиям) приводит в шаблоне спецификации требований такие разделы, как модель БД (логическая), требования к пользовательским и внешним интерфейсам, etc.
А еще часто залезть в БД, посмотреть на структуру, связи, атрибуты, а так же посмотреть код работающей системы — чуть ли не единственный источник требований. И об этом тоже пишут уважаемые авторы книг, по которым сдается сертификат по системному анализу. Наверное, мне стоило всюду в статье использовать термин «системный аналитик», а не просто аналитик.
Хотя, будем откровенны, у нас часто бизнес аналитиков называют системными и наоборот :)
Мнением архитектора и других специалистов никто не злоупотребляет.
Но, всё же, вы недооцениваете труд и знания аналитиков:) Тот же Вигерс (классика по требованиям) приводит в шаблоне спецификации требований такие разделы, как модель БД (логическая), требования к пользовательским и внешним интерфейсам, etc.
А еще часто залезть в БД, посмотреть на структуру, связи, атрибуты, а так же посмотреть код работающей системы — чуть ли не единственный источник требований. И об этом тоже пишут уважаемые авторы книг, по которым сдается сертификат по системному анализу. Наверное, мне стоило всюду в статье использовать термин «системный аналитик», а не просто аналитик.
Хотя, будем откровенны, у нас часто бизнес аналитиков называют системными и наоборот :)
Ну нет. Хороший PM/Аналитик это никак не медсестра. Это психотерапевт. А отличный PM/Аналитик — это психотерапевт, владеющий эриксоновским гипнозом.
Есть еще вопрос ответсвенности. Если я оценил что-то в 70-90 часов, то я должен успеть это в указанное время. Если не успел, то должен нести за это какую-то ответственность. Хотя бы в виде отчета «как так получилось и что нужно сделать, чтобы не случилось опять». Если успел раньше — все равно нужно понять что было не так с оценкой, чтобы следующая получилась точнее.
Оценил аналитик реализацию в 20 часов. Кто несет ответственность, если разработчик не успел? А еще сроки, спущены свыше, снижают мотивацию разработчика в них уложиться.
Общение с заказчиком — ok. Команда оценила требование в 700-900 часов, доносим это до заказчика. Возможно, ему на эти деньги требование окажется не нужным вовсе. Или решат упростить решение так, чтобы уложиться в 90 часов. Но это роль PM, а не аналитика.
Я допускаю, что один человек в команде может выполнять несколько ролей. Но только если он же несет ответственность за свои действия и обладает компетенцией.
Оценил аналитик реализацию в 20 часов. Кто несет ответственность, если разработчик не успел? А еще сроки, спущены свыше, снижают мотивацию разработчика в них уложиться.
Общение с заказчиком — ok. Команда оценила требование в 700-900 часов, доносим это до заказчика. Возможно, ему на эти деньги требование окажется не нужным вовсе. Или решат упростить решение так, чтобы уложиться в 90 часов. Но это роль PM, а не аналитика.
Я допускаю, что один человек в команде может выполнять несколько ролей. Но только если он же несет ответственность за свои действия и обладает компетенцией.
Здравствуйте!
Спасибо за комментарий.
Правильно я понимаю вашу мысль, что аналитик должен заниматься только требованиями и не распыляться на другие задачи?
Так складывалось неднократно, что в мои обязанности, как аналитика, входила также и оценка сроков.
При необходимости, привлекала к этому процессу программистов, тестировщиков, админа, дизайнеров. Стандартные, несложные проекты сама могла оценить. К счастью, заказчики не жаловались.
Спасибо за комментарий.
Правильно я понимаю вашу мысль, что аналитик должен заниматься только требованиями и не распыляться на другие задачи?
Так складывалось неднократно, что в мои обязанности, как аналитика, входила также и оценка сроков.
При необходимости, привлекала к этому процессу программистов, тестировщиков, админа, дизайнеров. Стандартные, несложные проекты сама могла оценить. К счастью, заказчики не жаловались.
Спасибо за ваш комментарий, за ваш опыт.
Действительно, если задача не стандартная, то я общаюсь с командой (и не только с программистами, а и с дизайнерами, тестировщиками). Мы совместными усилиями разрабатываем решение или варианты решений, после чего предложение озвучивается заказчику или менеджеру проекта.
Неужели так смутила фраза в статье, что аналитик принимает участие и на этапе обсуждения бизнес идеи, и что-то может подсказать?
Мне кажется, что это неплохой вариант, ведь аналитику потом писать требования, пусть будет в курсе с самого начала проекта.
Возможно, у вас другой опыт, процесс организован иначе. Я описала свой опыт.
Действительно, если задача не стандартная, то я общаюсь с командой (и не только с программистами, а и с дизайнерами, тестировщиками). Мы совместными усилиями разрабатываем решение или варианты решений, после чего предложение озвучивается заказчику или менеджеру проекта.
Неужели так смутила фраза в статье, что аналитик принимает участие и на этапе обсуждения бизнес идеи, и что-то может подсказать?
Мне кажется, что это неплохой вариант, ведь аналитику потом писать требования, пусть будет в курсе с самого начала проекта.
Возможно, у вас другой опыт, процесс организован иначе. Я описала свой опыт.
Нет, общение это нормально и обсуждение бизнес идеи тоже. Просто мне очень странно что по вашим словам вы имеете право конечного решения, организовываете встречи с кем считаете нужным ну и вообще getting things done. Точнее странно не это что вы это всё делаете а то что вы говорите что вы работаете Аналитиком а не Product Owner/ VP/ Architect. T.e. если вы имеете опыт для таких вещей и можете создавать достойные продукты, почему вы работаете аналитиком а не тем же архитектором с зарплатой в мин 2 раза больше?
А какое отношение в описанной компании было к agile-технологиям разработки?
Мне одному кажется что существенную часть этих тайных знаний можно было почерпнуть меньше чем за год — внимательно изучив описания соответствующих вакансий на hh? Ну и Вигерса, да.
Крупная компания, которая в рамках своего «налаженного жизненного цикла» не предусматривает таких вещей как аналитическое сопровождение разработки и ставит джуниор-аналитика одного на достаточно весомую задачу, не дав ему хотя бы раз поработать в команде с более опытным наставником — это как-то не очень монтируется с налаженными процессами.
Я правильно понимаю что заказчики — госбюджетные?
Крупная компания, которая в рамках своего «налаженного жизненного цикла» не предусматривает таких вещей как аналитическое сопровождение разработки и ставит джуниор-аналитика одного на достаточно весомую задачу, не дав ему хотя бы раз поработать в команде с более опытным наставником — это как-то не очень монтируется с налаженными процессами.
Я правильно понимаю что заказчики — госбюджетные?
А как вы проводите верификацию полученного продукта на соответствие результатам работы аналитика?
Добрый день!
Путем поддержки постоянной обратной связи с заказчиком.
Путем поддержки постоянной обратной связи с заказчиком.
Заказчик документы ваши читает?
Или имеется в виду, что вы передаете все заказчику со словами — верифицируй?
Или имеется в виду, что вы передаете все заказчику со словами — верифицируй?
А ко мне начали приходить с вопросами тестировщики (первый раз в жизни!). Они нашли отличия между требованиями и реализацией (вот так сюрприз!)
Предполагаю, что программисты тоже нашли отличия между требованиями и реализацией, потому как реализация это их работа. Или вернее, у них были вопросы, как именно реализовать конкретное требование. И они могли сообщить об этом гораздо раньше. Но они никому ничего не сказали, потому что:
— Их никто не спрашивал
— Это добавит им работы (за то же время и за те же деньги)
— Как скажут, так и переделаем (можно сделать и так и так без особых усилий)
По моему опыту, чаще встречается первый вариант, реже второй, иногда третий. Да, потом вопросы решаются; программистам говорят «надо сделать вот так»; просто реализация затягивается и время уходит. А можно было сразу спросить программистов (или архитекторов, если они есть)
Здравствуйте, спасибо за комментарий!
Правды ради стоит сказать, что в описанной истории на документе таки была подпись руководителя программистов и (формально) вопросов у него не было.
Там именно некоторые требования звучали неконкретно, их можно было интерпретировать по-разному. Программистам все было понятно. Но поняли неправильно. Тестировщики интерпретировали их, как и я, а программисты иначе.
Но да, не могу не согласиться, что нужно программисто спрашивать, обсуждать требования. И об этом как раз пункты 3.2 и 3.3 в статье.
Правды ради стоит сказать, что в описанной истории на документе таки была подпись руководителя программистов и (формально) вопросов у него не было.
Там именно некоторые требования звучали неконкретно, их можно было интерпретировать по-разному. Программистам все было понятно. Но поняли неправильно. Тестировщики интерпретировали их, как и я, а программисты иначе.
Но да, не могу не согласиться, что нужно программисто спрашивать, обсуждать требования. И об этом как раз пункты 3.2 и 3.3 в статье.
В середине 90-х я работал в команде программистом где был ирландец-экономист выполнявший роль аналитика в проекте. Выполнял свою работу он просто замечательно — хотя большую часть времени просто сидел уставившись в потолок.
Самое важное что я уяснил себе при этом — аналитик — это даже не человек глубоко разбирающийся в какой-либо прикладной области, а человек, отвечающий работающий на стыках нескольких прикладных областей, отвечающий за взаимное понимание между специалистами из этих прикладных областей. И работа эта не отчитался-закончил а весьма длительный процесс. Тот проект длился более года.
Тот что описали Вы в некоторой мере прошёл и я, но с отличиями. Я сам на момент найма аналитиком являлся высококлассным программистом.
Описание задания действительно должно быть как можно более полым и понятным для всех участников проекта.
Большинство тн стандартов для составления документации на практике просто вредно использовать, поскольку изобразив какой-нибудь процесс в какой-нибудь нотации ты уже практически не можешь объяснить его прикладном специалисту.
Некоторые из правил, которые для себя выработал.
Пиши много и нормальным человеческим языком.
Перечитывай что написал.
Есть вопрос — постарайся спросить у того к кому он относится а не выдумывай
Если у тебя есть мнение, что это правильно, то скорее всего ты ошибешься, если ни с кем это не обсуждал.
Ты не умнее другого, а уж тем более у тебя нет такого же практического опыта как у прикладного специалиста.
Клиент не всегда прав — клиент может быть…
Не трать много времени на общение с операционистами набранными по объявлению или людьми которые уже сотню лет просто вбивают одни и те же данные в одну таблицу.
Контролируй ход проекта — без присмотра проект может укатить вообще не в ту степь.
Самое важное что я уяснил себе при этом — аналитик — это даже не человек глубоко разбирающийся в какой-либо прикладной области, а человек, отвечающий работающий на стыках нескольких прикладных областей, отвечающий за взаимное понимание между специалистами из этих прикладных областей. И работа эта не отчитался-закончил а весьма длительный процесс. Тот проект длился более года.
Тот что описали Вы в некоторой мере прошёл и я, но с отличиями. Я сам на момент найма аналитиком являлся высококлассным программистом.
Описание задания действительно должно быть как можно более полым и понятным для всех участников проекта.
Большинство тн стандартов для составления документации на практике просто вредно использовать, поскольку изобразив какой-нибудь процесс в какой-нибудь нотации ты уже практически не можешь объяснить его прикладном специалисту.
Некоторые из правил, которые для себя выработал.
Пиши много и нормальным человеческим языком.
Перечитывай что написал.
Есть вопрос — постарайся спросить у того к кому он относится а не выдумывай
Если у тебя есть мнение, что это правильно, то скорее всего ты ошибешься, если ни с кем это не обсуждал.
Ты не умнее другого, а уж тем более у тебя нет такого же практического опыта как у прикладного специалиста.
Клиент не всегда прав — клиент может быть…
Не трать много времени на общение с операционистами набранными по объявлению или людьми которые уже сотню лет просто вбивают одни и те же данные в одну таблицу.
Контролируй ход проекта — без присмотра проект может укатить вообще не в ту степь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Путь аналитика. Работа над ошибками