Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 50
>> будут ли они продавать…
Продавать нужно какашку, годную вещь сами купят.
Продавать нужно какашку, годную вещь сами купят.
Эх, тяжело вам наверное в реальном мире живется :)
Это же не антивирус в коробке. Такие вещи продаются и внедряются годами.
Ага, не надо писать резюме и отвечать на вопросы на собеседовании. Просто будет умным и вас везде возьмут и дадут много денег.
Звучит как-то странно, не так ли?
Звучит как-то странно, не так ли?
Вы свое резюме печатаете в газете, расклеиваете на заборах, его зачитывают по радио и демонстрируют по телевизору в перерывах футбольных матчей? «Красивый, умный, в меру упитанный мужчина в самом расцвете сил решит все ваши проблемы, стучите в аську, и пусть весь мир подождет, ведь вы достойны лучшего специалиста, только здесь, только сейчас и только в честь дня рождения канадской компании скидки при приеме на работу!».
Коллеги, это мой первый пост на Хабре, и я был бы очень признателен минусующим за фитбэк. Хотелось бы понять, где накосячил. Заранее спасибо.
Я плюсанул (как минимум за старания), но может минусуют за излишне официальный стиль речи? Все эти «сбор требований к системе» и «реинжиниринг бизнес-процессов» звучат достаточно скучно.
Может стоит описать это более неформальным языком, представьте, будто вы рассказываете о том, чем вы занимаетесь, своим друзьям или девушке, а не какой-нибудь строгой комиссии.
Или хотя бы добавьте к скучным сухим определениям больше примеров из жизни.
Может стоит описать это более неформальным языком, представьте, будто вы рассказываете о том, чем вы занимаетесь, своим друзьям или девушке, а не какой-нибудь строгой комиссии.
Или хотя бы добавьте к скучным сухим определениям больше примеров из жизни.
Да, есть такой грех. Просто требования и пишутся сухим формальным языком. Я думал он будем уместен и в статье по аналитике. Похоже я ошибся — буду исправляться. Спасибо!
А вот девушке своей я объяснял чем занимаюсь чуть ли ни на примерах персонажей из русских народных сказок :) Вряд ли здесь такое будет уместно
А вот девушке своей я объяснял чем занимаюсь чуть ли ни на примерах персонажей из русских народных сказок :) Вряд ли здесь такое будет уместно
>Просто требования и пишутся сухим формальным языком.
А вот и зря. Вы пишите требования чтобы донести мысли до окружающих, а мысль гораздо лучше доносится с подкреплением эмоциями. Я давно отказался от сухости в описаниях и результаты стали намного лучше. Это конечно может на понравиться начальству, зацикленному на формалистике, но это уже ваша воля выбирать, где работать.
А вот и зря. Вы пишите требования чтобы донести мысли до окружающих, а мысль гораздо лучше доносится с подкреплением эмоциями. Я давно отказался от сухости в описаниях и результаты стали намного лучше. Это конечно может на понравиться начальству, зацикленному на формалистике, но это уже ваша воля выбирать, где работать.
«Пишутся» это скорее уже фиксация. Едва ли в ТЗ для крупного гос. заказчика будут уместны эмоции. Доносятся же мысли обычно раньше — на совещаниях и конф. колах. Там, конечно, язык куда боле живой. Иногда даже слишком живой :)
Но что я, судя по всему, точно сделал зря, так это выбрал сухой стиль изложения для этой статьи на Хабре. Не стоило насиловать Ваше восприятие формализованным текстом. Исправлюсь.
Но что я, судя по всему, точно сделал зря, так это выбрал сухой стиль изложения для этой статьи на Хабре. Не стоило насиловать Ваше восприятие формализованным текстом. Исправлюсь.
>До сих пор от некоторых разработчиков (хотя сейчас уже очень редко) можно услышать, что аналитики (равно как руководители проектов, менеджеры по продукту и т.д.) не только не вносят полезный вклад в дело, но и просто «мешаются под ногами». Лезут, понимаешь, со своими процессами, бумажками и прочей бюрократией — не дают простому девелоперу спокойно работать (смайл).
Возможно, многие хабралюди действительно так думают :). Тут уже ничего не поделаешь.
Возможно, многие хабралюди действительно так думают :). Тут уже ничего не поделаешь.
Коллеги, добавляющие пост в избранное, отпишитесь, пожалуйста, какие еще темы были бы Вам интересны.
Таким образом, в случае необходимости включить в «Техническое задание» модель базы данных Системы или диаграммы классов нужно понимать, что в этом случае:
Произойдет смешивание в одном документе результатов различных типов работ, выполняемых разными людьми (аналитиком и архитектором).
и
Однако некоторые отступления, такие как включение в «Техническое задание» спроектированных макетов интерфейса (без дизайна/оформления), допустимы, т.к. выполняются теми же людьми, которые разрабатывают само техническое задание.
А почему архитекторов нельзя смешивать, а проектировщиков интерфейса можно? Точнее, мне непонятно почему архитектор не входит в команду разработчиков ТЗ, а проектировщик входит?
Я имел ввиду, что не стоит включать в ТЗ результаты «тяжелых» работ этапа проектирования, выполняемых архитектором. Макеты интерфейса — тоже проектирование, но трудозатраты на него как правило меньше, и выполняется оно тем же аналитиком, который пишет ТЗ. Поэтому, хотя логически это не правильно, в ТЗ все-таки можно включать макеты UI, т.к. это дается малой кровью.
Вы молодец, потому что защищаете подход, где каждый этап разработки должен выполнять отдельный специалист.
Что касается терминов, то в моем понимании, макет интерфейса — неработающая модель, выполненная в натуральную величину и выглядящая так, как будет выглядеть работающий экземпляр (тут есть терминология с которой я согласен), а это большой отдельный труд. В общем, не буду цепляться к словам, вопросов больше нет.
Написал же я потому (я не проектировщик интерфейсов), что надоело видеть системы без проработанного интерфейса и, зачастую, это формулируется как раз в виде «проходная» — не «тяжелая» работа. Допускаю, что когда стоишь перед горой всяких деталей от нового, большого проекта, то думаешь больше о том как собрать из них летающую конструкцию, а не об удобстве пассажиров… пока сам не окажешься на месте пассажира :) в общем, уважайте труд юзабилистов, они экономят наши нервы :)
Что касается терминов, то в моем понимании, макет интерфейса — неработающая модель, выполненная в натуральную величину и выглядящая так, как будет выглядеть работающий экземпляр (тут есть терминология с которой я согласен), а это большой отдельный труд. В общем, не буду цепляться к словам, вопросов больше нет.
Написал же я потому (я не проектировщик интерфейсов), что надоело видеть системы без проработанного интерфейса и, зачастую, это формулируется как раз в виде «проходная» — не «тяжелая» работа. Допускаю, что когда стоишь перед горой всяких деталей от нового, большого проекта, то думаешь больше о том как собрать из них летающую конструкцию, а не об удобстве пассажиров… пока сам не окажешься на месте пассажира :) в общем, уважайте труд юзабилистов, они экономят наши нервы :)
почему же невозможно, бывают всякие варианты: www.jet.msk.su/careers/obuchenie/obuchayushchaya_programma_po_podgotovke_it_analitikov.php
сбор, анализ, формализация и согласование требований к системе.
Другими словами, управление требованиями на протяжении всего их жизненного цикла.
У вас тут классическая путаница. То, что описано в первой строчке — это разработка требований.
То, что во второй — управление требвоаниями — совсем другая работа, ей занимается менеджер.
По поводу lifelong learning — где вы взяли слова «PMbook» и «фитбэк» ?)
То, что во второй — управление требованиями — совсем другая работа, ей занимается менеджер.
Признаться, на практике ни разу не сталкивался с ситуацией, когда менеджер участвует в процессе управления требованиями более, чем на уровне отслеживания статусов ключевых из них. Даже на довольно крупных проектах не попадалось подобного разделения. Весь жизненный цикл требований всегда контролируется аналитиком, иначе будет бедлам.
Если Вы имеете ввиду менеджера продукта, то в нашей действительности это обычно на 80% тот же аналитик с некоторыми дополнительными обязанностями/полномочиями, вроде участия в маркетинговых активностях.
Управление требованиями — это принятие управленческий решений о:
1. Приоритетах требований
2. Рамках продукта (какие требования включать, какие — нет), оно же — scope management из того же PMBOK, включая сортировку входящих внешних требований — какие требования из других проектов включать, а какие — нет.
3. Рамках итерации
4. Чего проект требует от других проектов — исходящие требования
Эти решения принимает менеджер, и даже если выдвигает часть из них аналитик — всё равно несёт ответственность за них он.
То, что физически в учётной системе атрибуты «Приоритет, Релиз, Итерация, Источник, Потребитель» проставляет, например, аналитик, ещё не делает его «управленцем требований», он тут просто учётчик, оператор БД.
Также, технически, под гриф «управления требованиями» попадают:
5. Управление статусом требований и
5. Управление внутренними трассировками требований
7. Управление трассировками требований на другие артефакты проекта
С этими атрибутами действительно менеджеру возиться не интересно и он может доверять всю эту работу аналитику.
Но если посмотреть на жизненный цикл требований и на трассировки, то станет понятно, что аналитик отвечает только за часть переходов и за внутренние трассировки, а за переходы типа «разработано — протестировано» и за трассировки требований на тесты, например, отвечает уже тестировщик.
1. Приоритетах требований
2. Рамках продукта (какие требования включать, какие — нет), оно же — scope management из того же PMBOK, включая сортировку входящих внешних требований — какие требования из других проектов включать, а какие — нет.
3. Рамках итерации
4. Чего проект требует от других проектов — исходящие требования
Эти решения принимает менеджер, и даже если выдвигает часть из них аналитик — всё равно несёт ответственность за них он.
То, что физически в учётной системе атрибуты «Приоритет, Релиз, Итерация, Источник, Потребитель» проставляет, например, аналитик, ещё не делает его «управленцем требований», он тут просто учётчик, оператор БД.
Также, технически, под гриф «управления требованиями» попадают:
5. Управление статусом требований и
5. Управление внутренними трассировками требований
7. Управление трассировками требований на другие артефакты проекта
С этими атрибутами действительно менеджеру возиться не интересно и он может доверять всю эту работу аналитику.
Но если посмотреть на жизненный цикл требований и на трассировки, то станет понятно, что аналитик отвечает только за часть переходов и за внутренние трассировки, а за переходы типа «разработано — протестировано» и за трассировки требований на тесты, например, отвечает уже тестировщик.
Приоритезация требований — задача заказчика с помощью аналитика(-ов) исполнителя. Но никак не менеджера исполнителя. Следующие 2 пункта РП так же может только курировать. Он сам не определяет ни рамки (а лишь согласовывает с заказчиком то, что предварительно оговорено с аналитиком… а еще перед этим — с аккаунтом) и сам не определяет границы итераций, т.к. для этого надо как минимум четко понимать взаимосвязи между требованиями. Он может лишь согласовывать и утверждать их.
Я не хочу спорить о смысле формальных терминов, я просто имел ввиду что по сути управление требованиями — задача аналитика. А то что РП в ней организационно участвует — так он так же участвует в большинстве проектных активностей.
Извиняюсь, если некорректно сформулировал. Я просто хотел донести суть.
Кстати, переход «разработано — протестировано» тоже бывает организован по-разному. Часто реализацию ключевых требований полезно «пропускать» через аналитика, чтобы обеспечить высокоуровневую проверку (чтобы исключить ситуацию, когда тестеры убьют неделю на тестирование того, что в принципе должно работать по другому… причем такая ситуация может быть не только из-за нечетко сформулированных требований, но и еще из-за ряда причин, таких, например, как квалификация самих тестировщиков… ничего плохого не хочу про них сказать, но бывают ситуации когда на проекте временно работают только тест-джуниоры).
Я не хочу спорить о смысле формальных терминов, я просто имел ввиду что по сути управление требованиями — задача аналитика. А то что РП в ней организационно участвует — так он так же участвует в большинстве проектных активностей.
Извиняюсь, если некорректно сформулировал. Я просто хотел донести суть.
Кстати, переход «разработано — протестировано» тоже бывает организован по-разному. Часто реализацию ключевых требований полезно «пропускать» через аналитика, чтобы обеспечить высокоуровневую проверку (чтобы исключить ситуацию, когда тестеры убьют неделю на тестирование того, что в принципе должно работать по другому… причем такая ситуация может быть не только из-за нечетко сформулированных требований, но и еще из-за ряда причин, таких, например, как квалификация самих тестировщиков… ничего плохого не хочу про них сказать, но бывают ситуации когда на проекте временно работают только тест-джуниоры).
А я имею в виду, что управление требованиями — это не задача аналитика. Прежде всего потому, что управление — это управление, а разработка — это разработка: www.analystdays.com/talk.sdf/analystdays/analystdays1/talks/7518
И я могу это утверждать с позиции опыта руководителя отдела в 30 аналитиков с попытками отвечать за управление требованиями.
И я могу это утверждать с позиции опыта руководителя отдела в 30 аналитиков с попытками отвечать за управление требованиями.
По поводу классификации требований — и как же вы интересно в работе отличаете функциональные функциональные требования от функциональных нефункциональных? )
Какие ещё есть подходы, делюсь:
1. www.facebook.com/photo.php?fbid=10151692860420828&set=o.517711938247584&type=1&theater
2. blogs.uml2.ru/node/273
1. www.facebook.com/photo.php?fbid=10151692860420828&set=o.517711938247584&type=1&theater
2. blogs.uml2.ru/node/273
и как же вы интересно в работе отличаете функциональные функциональные требования от функциональных нефункциональных?
получается, что так, как предложено во второй Вашей ссылке — зовем их системными (в классификации по уровню)
Какие ещё есть подходы, делюсь
Было бы интересно почитать про опыт практического применения первого подхода. На первый взгляд, он выглядит перегруженным. А второй по сути совпадает с описанным в статье.
Кстати, хотел поблагодарить за интересные видео (В чём заключается работа системного аналитика (видео)), и узнать, планируете ли Вы продолжать активности по летней школе системного анализа?
А что вы понимаете под «практическим применением»?
Задача классификации в таком виде — показать картину понятий и взаимоотношений между ними. Чтобы, например, когда специалист слышит слово use case и использует их в работе, он понимал, что это такое в терминах видов требований — а именно, трассировка пользовательских требований на технические.
Наличие такой классификации не обязывает использовать все их виды и форматы представления в работе — они определяются опытом участников и контекстом проекта.
Задача классификации в таком виде — показать картину понятий и взаимоотношений между ними. Чтобы, например, когда специалист слышит слово use case и использует их в работе, он понимал, что это такое в терминах видов требований — а именно, трассировка пользовательских требований на технические.
Наличие такой классификации не обязывает использовать все их виды и форматы представления в работе — они определяются опытом участников и контекстом проекта.
Летнюю школу пока продолжать/повторять не планируем.
Своих целей мы 1-й школой добились, а как формат — марафон — она тяжеловата и для ведущих и для участников.
Будем делать короткие модули (1-4 недели), но скорее только в онлайне, за деньги, но не очень дорого.
Своих целей мы 1-й школой добились, а как формат — марафон — она тяжеловата и для ведущих и для участников.
Будем делать короткие модули (1-4 недели), но скорее только в онлайне, за деньги, но не очень дорого.
И ещё по школе — мы прямо сейчас ведём «весеннюю школу», которую спонсирует Джет: habrahabr.ru/post/178475/#comment_6195579
Enterprise это какой-то другой мир в IT, чего там только не придумали. Обычному честному быдлокодеру читать страшно.
Привет
Я работаю аналитиком, но подход, описанный вами, в сборе требований расстраивает меня чуть боле чем полностью. У меня есть несколько вопросов к вам:
— насколько часто складывается ситуация, когда требования, описанные в ТЗ, устаревают прежде чем вы закончили писать этот самый ТЗ? В моей практике это каждый первый проект.
— Кто потребитель ваших документов? Это практически непосильная работа для разработчиков прочитать талмуд в 100 страниц со всякими UML диаграммами и прочей ересью. Если учесть п. 1, то становится понятно, что девелоперы на это смотрят, как на пустую трату времени.
— Ну и пожалуй самый важный вопрос. Как удостовериться, что програмулька, на анализ которой ушло пол года, а на разработку еще год полностью соответствует требованиям заказчика.
Я работаю аналитиком, но подход, описанный вами, в сборе требований расстраивает меня чуть боле чем полностью. У меня есть несколько вопросов к вам:
— насколько часто складывается ситуация, когда требования, описанные в ТЗ, устаревают прежде чем вы закончили писать этот самый ТЗ? В моей практике это каждый первый проект.
— Кто потребитель ваших документов? Это практически непосильная работа для разработчиков прочитать талмуд в 100 страниц со всякими UML диаграммами и прочей ересью. Если учесть п. 1, то становится понятно, что девелоперы на это смотрят, как на пустую трату времени.
— Ну и пожалуй самый важный вопрос. Как удостовериться, что програмулька, на анализ которой ушло пол года, а на разработку еще год полностью соответствует требованиям заказчика.
Я не автор статьи, но попробую ответить на ваши вопросы (имею опыт работы системного/бизнес-аналитика):
— проблема, когда требования устаревают до окончания описания ТЗ — реальная проблема и в BABOK версии 3 над этим активно работают. В рассылке для волонтеров на его написание указывалось, что они хотят сосредоточиться на Agile подходе. Следует учесть, что полностью писать ТЗ заранее нужно далеко не везде и не всегда.
— потребителей документов может быть много – от руководства до программистов. Созданное ТЗ – это документ, имеющий ценность для бизнеса, ценность для разработчиков и т.д. Часто ожидается что с ТЗ будет работать некий менеджер проектов, который распределит работу между разработчиками. Из опыта работы разработчика – общаясь с заказчиком напрямую разработчики пишут код и много раз его переделывают, в то время как написанное качественно ТЗ значительно снижает кол-во переписываний кода (в чем согласно BABOK одна из основных задач бизнес-аналитика).
— для этого есть отдельный knowledge area в BABOK, как «Solution assessment and validation».
С удовольствием отвечу на вопросы, если у вас они есть :-)
— проблема, когда требования устаревают до окончания описания ТЗ — реальная проблема и в BABOK версии 3 над этим активно работают. В рассылке для волонтеров на его написание указывалось, что они хотят сосредоточиться на Agile подходе. Следует учесть, что полностью писать ТЗ заранее нужно далеко не везде и не всегда.
— потребителей документов может быть много – от руководства до программистов. Созданное ТЗ – это документ, имеющий ценность для бизнеса, ценность для разработчиков и т.д. Часто ожидается что с ТЗ будет работать некий менеджер проектов, который распределит работу между разработчиками. Из опыта работы разработчика – общаясь с заказчиком напрямую разработчики пишут код и много раз его переделывают, в то время как написанное качественно ТЗ значительно снижает кол-во переписываний кода (в чем согласно BABOK одна из основных задач бизнес-аналитика).
— для этого есть отдельный knowledge area в BABOK, как «Solution assessment and validation».
С удовольствием отвечу на вопросы, если у вас они есть :-)
К сожалению или к счастью, в современном мире под ТЗ понимается всё, что угодно — от действительно постановки задачи на проектирование с переченем функций до детальных спецификаций с макетами экранов, алгоритмами, детальными вариантами использования (что, например, по ГОСТУ уже скорее соответствует техническому проекту — ТП).
Эффективное ТЗ — это документ на 10 страниц, который разработчик прочитать может. Но если есть возможность, то лучше даже такое ТЗ представлять команде разработки, как и концепцию, на специальной встрече, чтобы убедиться, что они услышали, поняли, задали вопросы, получили ответы, сняли неопределённость и риски, и приняли то, что там описано.
А если засовывать в ТЗ все решения, то немудрено, что они устаревают к вечеру.
Как удостовериться — организовать:
1. Разработку приёмочных тестов и их исполнение — это в каскадном режиме, в общем случае не рекомендую.
2. Регулярную демонстрацию с приёмкой — в итерационном режиме, раз в 1-4 недели.
Эффективное ТЗ — это документ на 10 страниц, который разработчик прочитать может. Но если есть возможность, то лучше даже такое ТЗ представлять команде разработки, как и концепцию, на специальной встрече, чтобы убедиться, что они услышали, поняли, задали вопросы, получили ответы, сняли неопределённость и риски, и приняли то, что там описано.
А если засовывать в ТЗ все решения, то немудрено, что они устаревают к вечеру.
Как удостовериться — организовать:
1. Разработку приёмочных тестов и их исполнение — это в каскадном режиме, в общем случае не рекомендую.
2. Регулярную демонстрацию с приёмкой — в итерационном режиме, раз в 1-4 недели.
Спасибо за ответ, у меня не было желания столкнуться с вами лбами. Просто в вашей статье я увидел те проблемы, через которые я прошел раньше. То, что не работало во многоих моих проектах, вот меня и задело :)
Я выработал немного другой подход, более гибкий, спасибо за это книге Specification by Example. Если есть желание могу поделится опытом
Я выработал немного другой подход, более гибкий, спасибо за это книге Specification by Example. Если есть желание могу поделится опытом
Очень интересный вопрос Вы подняли. Действительно, требования стремительно устаревают. Но при этом ТЗ всё равно нужно: как правило, ТЗ — Приложение №1 к договору между исполнителем и заказчиком, и это единственный способ установить критерии успешного выполнения работы.
Один из вариантов — включать в ТЗ только ключевые требования (без детализации), и только бизнес-требования (никакого проектирования). Но и он не без недостатков. Во-первых, тогда ТЗ получается не по ГОСТ. Во-вторых, бывают ключевые требования низкого уровня, и непонятно, что с ними делать — например, когда жестко заданы платформа разработки, СУБД и/или язык программирования. В-третьих, даже ключевые бизнес-требования могут устареть, хотя это случается, к счастью, намного реже.
Другой вариант — работать полностью на устной договоренности, то есть в договоре что-то условно (рамочно) зафиксировали, а дальше каждое изменение согласовываем. Вариант работает до первого конфликта мировоззрений. Всё, что не зафиксировано письменно, оказывается в момент конфликта никогда не существовавшим.
Третий вариант — работать по Time&Materials. Не получается, когда у заказчика бюджет жестко фиксирован, и в нашей сфере это почти всегда так. Кроме того, вариант оправдан только в случае добросовестного и дисциплинированного разработчика, который не будет тупо проедать деньги заказчика.
В реальности получается что-то среднее между этими тремя вариантами. То есть, составляем договор и ТЗ, в которое стараемся вписывать только самое важное, что вроде бы не должно меняться в ходе проекта. В договор закладываем заранее избыточные трудозатраты на непредвиденные доработки. В ходе работы договариваемся, какие требования будем принимать формально, а какие — придирчиво. Например, если какое-то требование в ТЗ есть, но уже не актуально — значит, пусть будет, но для галочки.
Всё равно, конечно, получается плохо формализовано и далеко от идеала, но как по-другому — непонятно.
Один из вариантов — включать в ТЗ только ключевые требования (без детализации), и только бизнес-требования (никакого проектирования). Но и он не без недостатков. Во-первых, тогда ТЗ получается не по ГОСТ. Во-вторых, бывают ключевые требования низкого уровня, и непонятно, что с ними делать — например, когда жестко заданы платформа разработки, СУБД и/или язык программирования. В-третьих, даже ключевые бизнес-требования могут устареть, хотя это случается, к счастью, намного реже.
Другой вариант — работать полностью на устной договоренности, то есть в договоре что-то условно (рамочно) зафиксировали, а дальше каждое изменение согласовываем. Вариант работает до первого конфликта мировоззрений. Всё, что не зафиксировано письменно, оказывается в момент конфликта никогда не существовавшим.
Третий вариант — работать по Time&Materials. Не получается, когда у заказчика бюджет жестко фиксирован, и в нашей сфере это почти всегда так. Кроме того, вариант оправдан только в случае добросовестного и дисциплинированного разработчика, который не будет тупо проедать деньги заказчика.
В реальности получается что-то среднее между этими тремя вариантами. То есть, составляем договор и ТЗ, в которое стараемся вписывать только самое важное, что вроде бы не должно меняться в ходе проекта. В договор закладываем заранее избыточные трудозатраты на непредвиденные доработки. В ходе работы договариваемся, какие требования будем принимать формально, а какие — придирчиво. Например, если какое-то требование в ТЗ есть, но уже не актуально — значит, пусть будет, но для галочки.
Всё равно, конечно, получается плохо формализовано и далеко от идеала, но как по-другому — непонятно.
Почему ключевые требования — не по ГОСТ?
Почему важно, чтобы было по ГОСТ?
Почему вы называете ограничения на технологическую платформу низким уровнем?
Почему важно, чтобы было по ГОСТ?
Почему вы называете ограничения на технологическую платформу низким уровнем?
Почему вы называете ограничения на технологическую платформу низким уровнем?
Под низким уровнем я подразумеваю глубину проработки в иерархии цели -> требования -> проектирование -> реализация. По моему мнению, когда бизнес-требования работают только в терминах бизнеса, а оптимальная технологическая платформа определяется при проектировании, можно добиться большей эффективности автоматизации. Но это не всегда возможно.
Почему ключевые требования — не по ГОСТ?
Почему важно, чтобы было по ГОСТ?
Работать по ГОСТ важно, например, когда работаешь с госзаказчиком. Или отчитываешься по государственной субсидии. Кому-то это, действительно, не нужно, но для многих это серьезный фактор.
Структура ТЗ по ГОСТ 34 задает определенный ракурс для описания требований, и не всегда этот ракурс хорошо подходит для проектируемой системы. Хотя формально ГОСТ позволяет выкинуть половину разделов и добавить десяток своих, такое обращение со стандартом воспринимается экспертами очень настороженно, независимо от того, насколько это оправданно.
Здесь можно развить большой холивар на тему того, насколько хорош ГОСТ и как его «правильно готовить». Я не очень хочу на эту тему спорить, и готов согласиться с тем, что он вполне позволяет включить в себя все необходимые требования независимо от специфики проекта. Но последовательность разделов, группировка требований и терминология, принятые в стандартах 34-й серии лично мне иногда кажутся не вполне подходящими в ряде случаев. Например, при описании требований к веб-сайтам эта структура и терминология не является оптимальной.
Если выбор технологии обусловлен стоимостью интеграции с другими системами и стоимостью поддержи и разработки — то это бизнес-решение.
В продуктовой разработке ГОСТЫ не нужны.
Во внутренней разработке ГОСТЫ не нужны.
В заказной разработке ГОСТЫ нужны только для большинства госпроектов.
Итого, «не по ГОСТ» не является проблемой как минимум для 2-х контекстов из 3-х, а для заказной актуально для меньшей доли рынка (Доля B2G-проектов меньше B2B).
В продуктовой разработке ГОСТЫ не нужны.
Во внутренней разработке ГОСТЫ не нужны.
В заказной разработке ГОСТЫ нужны только для большинства госпроектов.
Итого, «не по ГОСТ» не является проблемой как минимум для 2-х контекстов из 3-х, а для заказной актуально для меньшей доли рынка (Доля B2G-проектов меньше B2B).
Доля B2G-проектов меньше B2B
С точки зрения количества проектов — может быть. С точки зрения объема рынка в рублях — уже не факт. И сведения, которые имеются у меня, говорят о том, что сложных масштабных внедрений больше именно в госсекторе.
Кроме того, госсектор чаще заказывает решения, отличные от типовых. Простой пример — бухгалтерия нужна каждой компании, а СМЭВ или ГАС «Выборы» — по штуке на всю страну.
Устаревание требований — действительно ключевая проблема. Согласен с коллегами — она отчасти решается использованием гибких методологий разработки, а отчасти — прописанием в уставе проекта, что все понимают, что требования не могут быть сформулированы сразу полностью и безошибочно, да еще и на длительный срок. Т.е. заказчик имеет право менять требования по ходу проекта, но при этом адекватно относится к соответствующему увеличению сроков и стоимости.
Что касается «недетализированных ТЗ», то это скорее Бизнес-требования. Если по вашим формулировкам программист не может начать работать, то это не ТЗ и не его аналог. ТЗ на 10 страниц — отличная идея, но не всегда реализуемая (например многие гос. заказчики требуют полное ТЗ до начала разработки). Но даже если мы напишем «монстра» на 250 стр, то его совсем не нужно читать полностью всем разработчикам. Куда удобнее использовать системы таск-трекинга, в талоны которых можно писать номера конкретных разделов ТЗ, где детализирован именно текущий таск.
Пример:
1. Аналитик Вася заводит фичу, что нужно добавить в админку новый справочник и указывает номер раздела ТЗ, где он описан
2. Dev lead Дима создает дочерние таски (доработать БД, создать новую вкладку на UI, реализовать импорт их XLSX и т.д.)
3. И когда дело доходит до разработчиков Саши, Маши и Вольдемара — то им либо не нужно смотреть в спеку вообще, либо — только в указанный раздел
Формальные способ (если резюмировать) — использование agile-овых методик. Косвенный — не скупиться на опытных аналитиков :)
Что касается «недетализированных ТЗ», то это скорее Бизнес-требования. Если по вашим формулировкам программист не может начать работать, то это не ТЗ и не его аналог. ТЗ на 10 страниц — отличная идея, но не всегда реализуемая (например многие гос. заказчики требуют полное ТЗ до начала разработки). Но даже если мы напишем «монстра» на 250 стр, то его совсем не нужно читать полностью всем разработчикам. Куда удобнее использовать системы таск-трекинга, в талоны которых можно писать номера конкретных разделов ТЗ, где детализирован именно текущий таск.
Пример:
1. Аналитик Вася заводит фичу, что нужно добавить в админку новый справочник и указывает номер раздела ТЗ, где он описан
2. Dev lead Дима создает дочерние таски (доработать БД, создать новую вкладку на UI, реализовать импорт их XLSX и т.д.)
3. И когда дело доходит до разработчиков Саши, Маши и Вольдемара — то им либо не нужно смотреть в спеку вообще, либо — только в указанный раздел
Как удостовериться, что програмулька, на анализ которой ушло пол года, а на разработку еще год полностью соответствует требованиям заказчика
Формальные способ (если резюмировать) — использование agile-овых методик. Косвенный — не скупиться на опытных аналитиков :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Становление аналитика