Хочу поделиться с вами правдивой историей о начале становления меня, как аналитика. Надеюсь, информация и выводы будут полезны начинающим системным аналитикам, бизнес-аналитикам.

1. Предыстория


Шел 2006 год. Мой путь системного аналитика начался в очень большой компании с хорошо налаженным жизненным циклом разработки.
Аналитики, менеджеры проектов, программисты, тестировщики, архитекторы работали в компании уже не один год. Задолго до моего появления в команде, в компании был утвержден формат спецификации требований, для всех удобный, привычный и понятный.

Мне сказали: делай так, и будет всем счастье. И стало так… до релиза первого серьезного проекта. Там-то и выяснилось, что просто грамотно следовать шаблону, а затем согласовать документ с необходимым списком лиц — недостаточно.

А выяснила я это уже через пол года работы аналитиком.

Что же я делала целые пол года, спросите вы?

Мне поручали описание небольших изменений, о которых так или иначе все были в курсе еще до моего прихода в компанию. Специалисты знали, что надо будет сделать; грядущие проекты неоднократно обсуждались ранее. А спецификация требований была скорее «бумажкой» для сбора подписей. Подписанный документ служил отмашкой: «можно начинать, людей выделили, бюджет утвердили и проект начат» (это я сейчас это понимаю, но не тогда!).

Еще в мои обязанности входило описание стандартных задач (конфигурация или мелкие, простые изменения в системе). Такие требования тоже были всем понятны с полуслова. В общем, документ был напоминанием, что надо сделать, но никто не вчитывался особо.

И вот через пол года мне поручили непростую задачу. В начале проекта я, как обычно, встретилась несколько раз с представителем заказчика, мы обсудили необходимые изменения, я их описала, согласовала со всеми. Получив на титульной страничке необходимый набор подписей я, очень довольная проделанной работой, отдала документ менеджеру и благополучно ушла в отпуск. «Моя работа в данном проекте завершена» — думала наивная я, опираясь на опыт предыдущих мелких задач.

Вот тут-то и началось самое интересное. На глубине описанного мною уровня детализации всем все было понятно. Все поставили свои подписи на документе. И отдали в работу программистам и тестировщикам. Когда дело дошло до тестирования, я уже давно вернулась из отпуска и занималась следующей задачей, на которую была выделена на 100%. А ко мне начали приходить с вопросами тестировщики (первый раз в жизни!). Они нашли отличия между требованиями и реализацией (вот так сюрприз!).

В общем, один и тот же текст трактовался по-разному: мною, программистами и тестировщиками. Спасибо, хоть с заказчиками у меня видение совпало. Потом мы вместе отстаивали нужный вариант. Описано было так, что, копнув чуть глубже, каждый плохо знакомый с процессами компании специалист мог найти то, что ему было удобнее/понятнее. Я была в шоке. Но быстро оправилась, «намотала эту ситуацию на ус» и провела работу над ошибками.

2. Какие я тогда выделила проблемные места


2.1. Качество спецификаций: требования были недостаточно конкретные. Была описана общая идея, при этом путей реализации можно было придумать несколько. А заказчику был важен конкретный вариант. Соответственно, нужно было либо очень подробно описать необходимое решение, либо ежедневно на этапе проектирования и реализации встречаться с командой, рассказывать, что требуется, смотреть, что получается. Учитывая бизнес процессы той компании, да еще и предстоящий отпуск, мне подошел бы первый вариант.

2.2. Участие аналитика в жизни проекта: я принимала участие только на начальных фазах жизненного цикла продукта. А аналитик нужен на всех этапах:
а) на фазе обсуждения бизнес идеи аналитик может подсказать:
— возможна ли реализация,
— способы и стоимость реализации.
б) фаза анализа и проектирования: ну, и так понятно;
в) фаза разработки и тестирования: отвечать на вопросы программистов и тестировщиков, активно принимать участие в обсуждениях. Тестировать, проверять реализацию основной функциональности. Просмотреть тест-кейсы или подсказать тестировщикам «хитрые» моменты, что нужно проверить. Всегда есть такие нюансы, что только аналитик держит в голове, а проверить их никому не приходит в голову :)
г) сдача в эксплуатацию и использование продукта: аналитик часто знает продукт лучше всех и может принять участие в подготовке презентаций продукта.

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

2.3. Согласование документа: практика показала, что подпись на документе (согласование документа) не всегда означает понимание требований подписываемым. Лучше лишний раз встретиться (хоть в скайпе) с теми, от кого что-то зависит и кому важны результаты проекта, провести презентацию и обсудить ключевые требования, если есть такая возможность. Убедиться, что вы «на одной волне».

И еще момент, который я хочу отметить сейчас, но тогда не задумывалась о нем.

2.4. Учет уровня команды и специфики проекта: этим злополучным проектом занимались новенькие в компании
разработчики и тестировщики. Если бы не этот нюанс, то, возможно, все прошло бы хорошо и для рассматриваемого проекта, даже без предыдущих пунктов.

Мораль: способ сбора и описания требований, а так же модель реализации проекта, зависит от конкретного проекта. Что необходимо учитывать:
— уровень команды;
— погружённость команды в проект;
— сработанность команды;
— тип задач (нечто стандартное для данной команды, конфигурация, либо сложный, уникальный проект);
— бюджет и сроки проекта;
— многое другое.

Но эта мысль посетила меня не сразу, и еще какое-то время я искала свою идеальную спецификацию.

3. Что я делала в сложившейся ситуации:


3.1. Много читала: в ход пошли Вигерс, Леффингуэлл, Коберн, и т.д. Я рассматривала примеры спецификаций, старалась почерпнуть максимум полезного и подходящего, и незамедлительно это использовала в работе.

3.2. Организовала своевременную обратную связь тестировщиков и программистов на ранних стадиях проекта:
менеджер проекта удивлялся, когда я просила выделить тестировщика для просмотра спецификации, но шел навстречу. Ведь есть такие вопросы, что приходят в голову только тестировщикам! И хорошо, когда они рассмотрены вовремя.

3.3. Собирала вместе кого-то из представителей заказчика, программистов, тестировщика, менеджера проекта перед запуском проекта: на такой встрече мы убеждались, что правильно понимаем друг друга, напоминали важные детали и т.п.

Спустя короткий период времени программисты стали отмечать прогресс и благодарить за спецификации.

И тут я поняла, что застопорилась на неком уровне и хочу двигаться дальше. У меня появилась навязчивая идея: узнать, как в других компаниях пишут спецификации, и почерпнуть что-то новое для себя. Нашлись форумы, сообщество аналитиков. Я читала «а как у других», рассматривала примеры, инициировала встречи и задавала вопросы.

Отдельно хочу отметить, что мир не без добрых людей, и малознакомые, но опытные аналитики ни разу мне не отказали во встрече и ответах на вопросы. Спасибо вам, дорогие коллеги. Поэтому, «ищите и найдете, стучите, и вам отворят».

Продолжение следует…

Комментарии (42)


  1. lair
    17.07.2015 12:42
    +1

    а) на фазе обсуждения бизнес идеи аналитик может подсказать:
    — возможна ли реализация,
    — способы и стоимость реализации.

    «Но как, Холмс»?

    Нам нужна система, которая будет обрабатывать сигналы о местоположении от 200+ тысяч пользователей и показывать их на карте с задержкой не более двух минут. Возможность, способы, стоимость?


    1. elena_g Автор
      17.07.2015 13:52

      Добрый день!
      Отвечу на Ваш первый вопрос на основании личного опыта. Сталкивалась с 2-мя ситуациями:
      1. Аналитик работает с системой, где требуются изменения (самая простая ситуация). Как правило, тут человек уже через несколько месяцев работы неплохо знает и предметную область, и возможности программистов, и архитектуру системы. Или знает, где подсмотреть, кого спросить. Может рассказать, что вот для этого изменения нужно доработать логику, для этого — менять архитектуру, но можно сделать что-то проще, но без изменений архитектуры, и т.п. По опыту знаю, что аналитик довольно быстро учится делать достаточно точные оценки в такой ситуации, если часто практикуется:)
      2. Нужно сделать оценку для кардинально новой разработки. Аналитик изучает предметную область, советуется со специалистами, и после проделанной работы предлагает варианты заказчику. Учитывается множество факторов, возможные технологии. Что быстро сделать под iOS, под андроид сложнее, и наоборот :)

      По поводу вашего второго вопроса: сходу не скажу, надо исследовать :) какая карта, платные или бесплатные возможности популярных карт? Какой сервер, какой канал, какая нагрузка? Пообщавшись с заказчиком и с экспертами, аналитик вам предложит варианты.


      1. lair
        17.07.2015 15:59

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

        На основании чего аналитик принимает решения, для чего нужно менять архитектуру, а для чего — нет, и какое изменение архитектуры «проще» или «сложнее»? Какую роль в команде играет архитектор?

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

        Так аналитик может подсказать, или аналитик может посоветоваться со специалистами и транслировать их мнение?

        какая карта, платные или бесплатные возможности популярных карт? Какой сервер, какой канал, какая нагрузка?

        Нагрузка озвучена, все остальное на ваше усмотрение. Интересуют возможные варианты с их плюсами/минусами и стоимостью.


        1. elena_g Автор
          17.07.2015 16:38

          Решения принимает на основании анализа системы (как ни банально это прозвучит), знаний и опыта. Бывают случаи (часто!), когда аналитик выполняет функцию архитектора. В разных проектах разное распределение ролей.

          По поводу подсказать или транслировать: оба варианта имеют место быть. Глупо злоупотреблять опытом гуру. Иногда нужно собрать их мнение и транслировать заказчику, это тоже работа аналитика, он выступает звеном между заказчиками и разработчиками.

          На счёт оценки системы: не могу сходу ответить. Оценка возможностей системы, существующих решений, уровня программистов и т.д. может занимать достаточно долгое время.


          1. lair
            17.07.2015 16:43
            +1

            Решения принимает на основании анализа системы (как ни банально это прозвучит), знаний и опыта.

            Откуда у аналитика (особенно — бизнес-аналитика) опыт, скажем, в проектировании (ну там — протоколы, партиционирование, вся эта требуха) распределенных систем с совместной работой?

            Бывают случаи (часто!), когда аналитик выполняет функцию архитектора.

            Я могу еще поверить в обратное (когда человек с основной ролью архитектора еще и выполняет роль аналитика); но надо понимать, в любом случае, что роли аналитика и архитектора фундаментально различны.

            На счёт оценки системы: не могу сходу ответить. Оценка возможностей системы, существующих решений, уровня программистов и т.д. может занимать достаточно долгое время.

            Это, извините, уже этап анализа. А вы написали, что аналитик может это подсказать на этапе обсуждения бизнес-идеи.


            1. elena_g Автор
              17.07.2015 16:55

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

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


              1. lair
                17.07.2015 16:59

                А откуда вообще берется опыт? Аналитику в принципе нужно много знать и уметь.

                Опыт берется из образования и проведенной работы. Надо просто помнить, что в голову к каждому человеку влезает не так много опыта, а работа аналитика сама по себе достаточно сложна, чтобы требовать full-time dedication.

                Сколько книг по архитектуре ПО лично вы прочитали?


                1. elena_g Автор
                  17.07.2015 19:20

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


                  1. SVVer
                    17.07.2015 19:45

                    А как вы разграничиваете роли аналитика, архитектора и проектировщика? Мне, честно говоря, тоже странно выполнение одним человеком ролей архитектора и аналитика одновременно. Я бы в этом случае предположил, что этот же человек и основной разработчик тоже.


                  1. lair
                    17.07.2015 21:28
                    +2

                    (достаточно? назовете хотя бы пару названий?)

                    Понимаете ли, я за свои сколько-то лет работы в отрасли не видел ни одного бизнес-аналитика, способного (а системных аналитиков не видел вообще ни одного живьем):

                    1. выбрать между реляционным и нереляционным хранилищем (и аргументировать свой выбор)
                    2. определить, строгая или отложенная (eventual) консистентность нужна в системе
                    3. правильно оценить срок интеграции учетной системы с системой документооборота (причем обе уже используются в компании несколько лет)


                    1. elena_g Автор
                      18.07.2015 15:18

                      А мне вот доводилось таких встречать.


                      1. lair
                        18.07.2015 15:41
                        +1

                        Зачем им тогда архитекторы в команде?


      1. Murlakatam
        17.07.2015 17:58

        Я как аналитик, могу смело сказать — по тонкому льду идете Елена, с таким подходом.
        Из моего опыта, такие решения мы принимаем командно, с привлечением и бизнеса и разработки. Причем, часто, предлагаемое изначально решение, в ходе дискуссии может сильно трансформироваться


        1. elena_g Автор
          17.07.2015 18:55

          Здравствуйте!
          спасибо за Ваш опыт!
          В моей практике простые или стандартные изменения оценивались аналитиками, более сложные — сообща. А вы все изменения командно оцениваете? Даже если заказчик просто узнает потенциальную возможность и примерные споки/влияние?


      1. yuriy-s
        18.07.2015 20:15
        +3

        Я интересовался ай-ти всю свою жизнь и начал программировать в детстве на вижуал Бейсике на украденном папой с работы компьютером в 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 и различием между способами хранения/аналитики этой даты?


        1. yuriy-s
          19.07.2015 03:32

          Ну а решение задачи выше может быть таким:

          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. Kaiser
          19.07.2015 23:22
          +1

          Поддерживаю.

          Оценки сроков от аналитика одна из частых причин срывов сроков в проекте. Когда стал работать с «русским бизнесом» был неприятно удивлен распространенности этого явления. Хуже разве что архитектура от аналитика.

          Здесь опыт нужен, чтобы в беседе с заказчиком определять проблемные места и подробнее доносить их до команды разработчиков. Тогда на встрече с разработчиками будет что обсудить: количество пользователей, лаг на карте, зачем нам все это нужно и какая у нас конечная цель, каковы критерии успеха. А не просто стоять человеком-телефоном и недоумевать.

          Главное обходить 2 крайности:
          — Заказчик часто озвучивает не функциональные требования, а свои представления о том, как это требование будет реализовано. Нужно уметь определить само требование.
          — Заказчик лучше аналитика знает что ему нужно. Не стоит мнить себя мега-экспертом и делать «как лучше». Нужно делать как просят.


          1. yuriy-s
            19.07.2015 23:50
            +1

            Именно поэтому работа аналитика именно то что и подразумевает «бизнес аналитика» а именно формулировка задачи в более менее конкретных терминах ( например user stories или SRS ). Т.е. задачей аналитика как раз является встречи с клиентом в результате которого появляется формулировка «нужна система, которая будет обрабатывать сигналы о местоположении от 200+ тысяч пользователей и показывать их на карте с задержкой не более двух минут.» а ещё лучше подробности которые описанные в виде формального документа ( «нужна система ( что именно? код с установкой? поддержка? какие языки? какие версии контроля? ), которая будет обрабатывать сигналы (какие устройства? какие страны? ) о местоположении от 200+ тысяч ( с прицелом на будущее или нет ?) пользователей и показывать ( как показывать? веб? мобильные эппы? ) их на карте с задержкой не более двух минут.»

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


            1. elena_g Автор
              20.07.2015 01:28

              Спасибо!
              Каждый должен заниматься своим делом, и делать его хорошо, согласна.
              Просто нет стандартной должностной инструкции аналитика. В зависимости от компании, от проекта, требования к такой роли варьируются. Часто происходит совмещение: аналитик+ПМ.
              Где-то аналитик занимается только функциональными требованиями, где-то — проектирует БД, составляет use cases (в том числе и вызов нужных API на соответствующих шагах сценария), моделирует прототипы пользовательского интерфейса, описывает правила интеграции систем.


              1. yuriy-s
                20.07.2015 02:28

                Я считаю что да. Т.е. бизнес аналитика это именно общение с клиентом и перевод этого общения в формальные требования для разработки. PM тоже довольно часто ОК — в небольших компаниях это часто может делать один человек.

                А вот архитектура/UX/DB это совсем не ОК. Без обид, но мнение разработчика ( если нет архитектора или тим лида ) тут более весомое чем ваше. Потому что более квалифицированное, конкретного опыта больше.

                PM/Аналитик это медсёстра. Они должны померять температуру, распросить пациента и написать в карточку симптомы болезни, успокоить больного и сказать что всё будет хорошо. Разработчики это врачи ( каждый со своей специализацией, кто-то фронтэнд, кто-то бэкенд, кто-то выбирает мобильную разработку ), тим лид это заведующий отделом а архитектор это глав-врач. У каждого своя роль и свой необходимый уровень квалификации. Представляете что бы было если бы медсестра составляла план лечения сложных пациентов? Вы бы хотели бы лечится в такой больнице? :)


                1. elena_g Автор
                  20.07.2015 13:56

                  Еще раз повторюсь:)
                  Мнением архитектора и других специалистов никто не злоупотребляет.
                  Но, всё же, вы недооцениваете труд и знания аналитиков:) Тот же Вигерс (классика по требованиям) приводит в шаблоне спецификации требований такие разделы, как модель БД (логическая), требования к пользовательским и внешним интерфейсам, etc.
                  А еще часто залезть в БД, посмотреть на структуру, связи, атрибуты, а так же посмотреть код работающей системы — чуть ли не единственный источник требований. И об этом тоже пишут уважаемые авторы книг, по которым сдается сертификат по системному анализу. Наверное, мне стоило всюду в статье использовать термин «системный аналитик», а не просто аналитик.
                  Хотя, будем откровенны, у нас часто бизнес аналитиков называют системными и наоборот :)


                  1. lair
                    20.07.2015 14:00
                    +1

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

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


                1. PavelSandovin
                  21.07.2015 11:05
                  +1

                  Ну нет. Хороший PM/Аналитик это никак не медсестра. Это психотерапевт. А отличный PM/Аналитик — это психотерапевт, владеющий эриксоновским гипнозом.


                  1. elena_g Автор
                    21.07.2015 14:30

                    Хорошая аналогия


              1. Kaiser
                20.07.2015 10:53
                +1

                Есть еще вопрос ответсвенности. Если я оценил что-то в 70-90 часов, то я должен успеть это в указанное время. Если не успел, то должен нести за это какую-то ответственность. Хотя бы в виде отчета «как так получилось и что нужно сделать, чтобы не случилось опять». Если успел раньше — все равно нужно понять что было не так с оценкой, чтобы следующая получилась точнее.

                Оценил аналитик реализацию в 20 часов. Кто несет ответственность, если разработчик не успел? А еще сроки, спущены свыше, снижают мотивацию разработчика в них уложиться.

                Общение с заказчиком — ok. Команда оценила требование в 700-900 часов, доносим это до заказчика. Возможно, ему на эти деньги требование окажется не нужным вовсе. Или решат упростить решение так, чтобы уложиться в 90 часов. Но это роль PM, а не аналитика.
                Я допускаю, что один человек в команде может выполнять несколько ролей. Но только если он же несет ответственность за свои действия и обладает компетенцией.


          1. elena_g Автор
            20.07.2015 00:55

            Здравствуйте!
            Спасибо за комментарий.
            Правильно я понимаю вашу мысль, что аналитик должен заниматься только требованиями и не распыляться на другие задачи?

            Так складывалось неднократно, что в мои обязанности, как аналитика, входила также и оценка сроков.
            При необходимости, привлекала к этому процессу программистов, тестировщиков, админа, дизайнеров. Стандартные, несложные проекты сама могла оценить. К счастью, заказчики не жаловались.


        1. elena_g Автор
          20.07.2015 00:13

          Спасибо за ваш комментарий, за ваш опыт.
          Действительно, если задача не стандартная, то я общаюсь с командой (и не только с программистами, а и с дизайнерами, тестировщиками). Мы совместными усилиями разрабатываем решение или варианты решений, после чего предложение озвучивается заказчику или менеджеру проекта.
          Неужели так смутила фраза в статье, что аналитик принимает участие и на этапе обсуждения бизнес идеи, и что-то может подсказать?
          Мне кажется, что это неплохой вариант, ведь аналитику потом писать требования, пусть будет в курсе с самого начала проекта.
          Возможно, у вас другой опыт, процесс организован иначе. Я описала свой опыт.


          1. yuriy-s
            20.07.2015 03:17

            Нет, общение это нормально и обсуждение бизнес идеи тоже. Просто мне очень странно что по вашим словам вы имеете право конечного решения, организовываете встречи с кем считаете нужным ну и вообще getting things done. Точнее странно не это что вы это всё делаете а то что вы говорите что вы работаете Аналитиком а не Product Owner/ VP/ Architect. T.e. если вы имеете опыт для таких вещей и можете создавать достойные продукты, почему вы работаете аналитиком а не тем же архитектором с зарплатой в мин 2 раза больше?


            1. elena_g Автор
              20.07.2015 14:01

              Я описывала в статье свои первые шаги, как аналитика, ошибки и выводы. Но последние годы я работала БА + ПМ. На зп не жалуюсь:)


  1. SVVer
    17.07.2015 13:08

    А какое отношение в описанной компании было к agile-технологиям разработки?


    1. elena_g Автор
      17.07.2015 14:04

      Здравствуйте!
      Когда я там начинала работать, отношений с agile у компании не было. А в году 2010 или 11-м некоторые менеджеры проектов стали смотреть в сторону agile и пробовать на подходящих проектах.


  1. AlexanderAnisimov
    17.07.2015 16:18
    +1

    Мне одному кажется что существенную часть этих тайных знаний можно было почерпнуть меньше чем за год — внимательно изучив описания соответствующих вакансий на hh? Ну и Вигерса, да.

    Крупная компания, которая в рамках своего «налаженного жизненного цикла» не предусматривает таких вещей как аналитическое сопровождение разработки и ставит джуниор-аналитика одного на достаточно весомую задачу, не дав ему хотя бы раз поработать в команде с более опытным наставником — это как-то не очень монтируется с налаженными процессами.

    Я правильно понимаю что заказчики — госбюджетные?


    1. elena_g Автор
      17.07.2015 16:25

      Здравствуйте!
      Можно получать знания по-разному. Что-то с hh почерпнуть, что-то — на основании книг, опыта, ошибок.
      Я поделилась ошибками и выводами первого полугодия работы. Кому-то может это пригодиться, кто-то научиться чему-то на моих ошибках. Буду рада.


    1. elena_g Автор
      17.07.2015 16:26

      Не госбюджетные заказчики.


  1. u_story
    17.07.2015 23:47

    А как вы проводите верификацию полученного продукта на соответствие результатам работы аналитика?


    1. elena_g Автор
      18.07.2015 11:15

      Добрый день!
      Путем поддержки постоянной обратной связи с заказчиком.


      1. u_story
        18.07.2015 11:42

        Заказчик документы ваши читает?
        Или имеется в виду, что вы передаете все заказчику со словами — верифицируй?


        1. elena_g Автор
          18.07.2015 15:17

          Прошу прощения, не так вопрос прочитала вначале.
          Тестировщики этим занимаются: составляют тест-кейсы и тестируют.


          1. u_story
            19.07.2015 10:47

            Т.е. вместе садитесь, проходите по документу и создаете планы тестирования?
            Я думал, что, возможно, используете какие-нибудь хитрые инструменты по преобразованию требований в тесты.


            1. elena_g Автор
              19.07.2015 23:42

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


  1. michael_vostrikov
    19.07.2015 18:24
    +1

    А ко мне начали приходить с вопросами тестировщики (первый раз в жизни!). Они нашли отличия между требованиями и реализацией (вот так сюрприз!)

    Предполагаю, что программисты тоже нашли отличия между требованиями и реализацией, потому как реализация это их работа. Или вернее, у них были вопросы, как именно реализовать конкретное требование. И они могли сообщить об этом гораздо раньше. Но они никому ничего не сказали, потому что:
    — Их никто не спрашивал
    — Это добавит им работы (за то же время и за те же деньги)
    — Как скажут, так и переделаем (можно сделать и так и так без особых усилий)

    По моему опыту, чаще встречается первый вариант, реже второй, иногда третий. Да, потом вопросы решаются; программистам говорят «надо сделать вот так»; просто реализация затягивается и время уходит. А можно было сразу спросить программистов (или архитекторов, если они есть)


    1. elena_g Автор
      19.07.2015 23:34

      Здравствуйте, спасибо за комментарий!
      Правды ради стоит сказать, что в описанной истории на документе таки была подпись руководителя программистов и (формально) вопросов у него не было.
      Там именно некоторые требования звучали неконкретно, их можно было интерпретировать по-разному. Программистам все было понятно. Но поняли неправильно. Тестировщики интерпретировали их, как и я, а программисты иначе.

      Но да, не могу не согласиться, что нужно программисто спрашивать, обсуждать требования. И об этом как раз пункты 3.2 и 3.3 в статье.