Меня зовут Ирина Гертовская, вся моя деятельность связана с разработкой в IT.
Работала во всех ролях, начиная от разработчика и тестировщика, была аналитиком, руководителем проектов и руководителем подразделения.
Занимаюсь обучением, выступаю на конференциях, участвую в организации «Летнего аналитического фестиваля».
На слайде перечислены те предметные области, в которых работают мои проекты – и сейчас я попробую свой опыт обобщить и вам передать.
Я глубоко убеждена, что успех системы закладывается на предпроекте. Именно на обследовании мы анализируем потребности и цели будущей системы, перекладываем их в затраты, рассчитываем нужное для разработки время и закладываем то, что будет в системе. От результатов предпроекта зависит, как мы систему сдадим.
Мы пройдем семь шагов и попробуем понять, какие предпосылки можно вытащить на предпроекте для успешной сдачи и потом функционирования системы.
По мнению Дерека Хитчинса, успешная система – это та, с которой добиваются успеха ключевые заинтересованные стороны, стейкхолдеры – те, ради кого мы работаем.
А Фредерик Брукс, который написал книгу «Мифический человеко-месяц», сказал: «Самое сложное – решить, что мы будем создавать».
Именно этим предпроект и занимается – определяет, что создавать в системе. Поэтому мы сейчас займемся потребностями, целями и задачами.
На первом шаге обследования мы должны определить, что будет результатом предпроекта. Не системы, а предпроекта.
На старте предпроекта мы должны определить:
-
Концепцию – но, если мы уже работаем в рамках системы, в отдельном виде концепция не нужна.
-
Границы проекта – определить MVP или дорожную карту, выстроить приоритеты.
-
Контрактные обязательства – их тоже может не быть, если это внутренняя разработка, там контракт не нужен.
На этом этапе важно фиксировать возникающие у нас вопросы, на которые мы не можем найти ответ в моменте. Т.е. открытые вопросы следует:
-
записывать в едином месте;
-
искать и фиксировать ответы;
-
контролировать ответы и учитывать их в обследовании.
Это все – функции аналитика, project owner’а и руководителя проекта. Причем, здесь аналитик должен выступать правой рукой руководителя проекта – заранее увидеть эти проблемы и обратить на них внимание руководителя, у которого много других забот. Фиксировать открытые вопросы очень важно.
Второй шаг – выявляем стейкхолдеров, тех, для кого нужна система. Это очень важно.
Не «что будет делать система», а «для кого система» – кто заинтересован в том, чтобы она была. Для кого мы ее строим, чьи интересы мы должны выполнить.
Не забывайте определение того, что такое заинтересованные стороны – оно есть в любом своде знаний PMBoK, BABOK.
Это группа лиц и/или один человек, которые:
-
могут влиять на систему;
-
могут оказаться под влиянием системы;
-
могут считать себя затронутыми системой – не быть затронутыми, а считать себя затронутыми, это тоже очень важно;
-
и могут повлиять на выбор путей реализации системы.
Заинтересованными сторонами могут быть те, кто находится совсем далеко, но при этом влияет на систему – возможно, это какие-нибудь, регуляторы, законодатели, еще кто-то. Регуляторы – это тоже стейкхолдеры.
Здесь на слайде перечислены примерные группы стейкхолдеров.
Помним, что в течение нашей работы над проектом всегда найдется еще хотя бы один стейкхолдер, которого мы не увидели на этапе предпроекта. Поэтому не стесняйтесь в ходе проекта их добавлять и исследовать потребности и цели.
Самые важные группы стейкхолдеров:
-
Ключевые – те, чьи интересы мы должны соблюсти в системе.
-
Критичные – те, кто влияет на решения и пути реализации. Сюда относятся:
-
разработчики – от них зависит, какими способами они могут это сделать;
-
регуляторы – те, кто задают правила. Это тоже очень важно.
-
Думайте о клиенте своего клиента. Система реализуется не только для тех, кто нам ее заказывает и будет работать в ней. А еще и для тех, ради кого работают пользователи системы. Например, система банка разрабатывается для работников банка, но для улучшения обслуживания клиентов банка. Т.е. система может не доходить до клиентов банка, но думать об их потребностях и проблемах нужно. Если система не будет решать их проблемы – клиенты банка уйдут в другой банк, наш клиент (банк) потеряет бизнес.
После того как у нас появились стейкхолдеры, мы определяем их цели и проблемы и указываем в концепции.
Следующий шаг – нужно изучить предметную область или, иными словами, домен.
Здесь нас интересуют:
-
Бизнес-процессы, этапы, переделы – нужно построить себе картинку, что вообще происходит.
-
Объекты.
-
Бизнес-правила – например, регулятор нам дает нормативку.
-
Внешние условия.
-
Сюда же можно отнести и возможности. Например, доступность интернета нам дала новые возможности – у нас изменился вызов такси, стала популярна доставка, и все это происходило на наших глазах.
Описание домена мы прописываем в концепцию. Пусть в двух-пяти предложениях, но важно указать в концепции, о чем речь.
Переходим к четвертому шагу – начинаем думать о том, ЗАЧЕМ нам система? Если мы не понимаем ДЛЯ КОГО (кто стейкхолдеры) и не понимаем ГДЕ (в каком домене или предметной области эта система), к этому шагу переходить рано. Это очень важно.
Но когда мы идем к стейкхолдерам и что-нибудь спрашиваем, они нам не говорят пользовательские или бизнес-требования требования. Они нам говорят о своих проблемах, о своих болях и, в лучшем случае, о своих потребностях. Люди вообще думают моделями.
Часто на обследовании аналитик начинает спрашивать, ему что-то отвечают, а потом он находит подробности в литературе, додумывает и спрашивает: «А вот это так?» – «Конечно, а как иначе?» Но мы-то откуда это знаем? Эти реальные потребности надо из ключевых стейкхолдеров как-то вытащить и с ними согласовать.
Для этого нужно подняться на уровень бизнес-целей.
Здесь немного определений, которые будут упоминаться дальше на схемах.
Зависимости требований:
-
Первое – мы приходим к заинтересованным сторонам и выясняем их требования.
-
Второе – на основании требований пишем спецификацию к ПО и отдаем ее в разработку.
-
Третье – после того как доработки сделаны, мы их приходим сдавать заказчику. Но результат стейкхолдеры принимают у нас не по переданным нам словам, а по той модели, которая у них в голове.
И вот тут идет разрыв.
Они нам говорят: «А почему вы это не сделали?» Мы отвечаем: «Так вы нам это не сказали». Что в корне неверно. Не делайте так!
Поэтому при сборе потребностей нужно:
-
Обязательно заглянуть в бизнес-цели – посмотреть, что они в целом хотят, ради чего они строят систему.
-
После этого, с учетом потребностей и бизнес-целей, построить спецификацию и передать в разработку.
-
Тогда сдавать систему заказчику нам будет легче.
Пятый шаг – ЧТО: какие функции должна выполнять наша система?
Мы выявили домен, выявили стейкхолдеров. А теперь мы приходим к нашей системе и определяем роли и основные функции:
-
Кто вообще в системе будет работать? Ранее у нас были стейкхолдеры, которые могут и не работать в системе – если, например, они регуляторы или пользуются результатами системы. А здесь мы рассматриваем уже роли и основные функции в нашей системе.
-
Какие функции должна выполнять система? Например, она должна содержать базу знаний, которую можно читать, актуализировать, выявлять какие-то нестыковки, архивировать неактуальные части.
-
Дорожная карта развития.
-
MVP и приоритеты разных частей. MVP – это минимальный жизнеспособный продукт. Это то, что мы покажем заказчику в первый момент, докажем, что мы понимаем что ему, заказчику нужно и что мы умеем делать. MVP должен показать, что идея будет работать. Вам нужно выбрать то, что вы будете показывать. Помните, что объять необъятное нельзя – выберите что-то конкретное и полезное заказчику.
-
Ограничения – вам нужно выявить, определить массу всяких ограничений.
-
Критерии успеха – как показать заказчику, что система выполняет задуманные заказчиком функции, удовлетворяет потребности, решает проблемы. Иногда сложно. Но полезно.
Шестой шаг, без которого система не взлетит – это подумать о внедрении.
О чем важно не забыть:
-
Нефункциональные требования:
-
какие нагрузки будут;
-
с какими скоростями должна работать система;
-
какие объемы;
-
какие периоды бесперебойной работы и т.д.
-
-
Организация внедрения:
-
Нужна ли новая оргструктура, или мы этой обойдемся?
-
Нужна ли миграция данных?
-
Нужно ли обучение персонала? На это надо хотя бы бегло посмотреть еще на предпроекте, когда мы поняли, для чего система, что мы хотим, чтобы она делала, хотя бы галочки поставить «надо» / «не надо». Что-то – обязательно, а что-то мы можем на второй этап перенести.
-
-
И ограничения, особенности:
-
Лицензирование – нужно или нет, что именно требует лицензирования.
-
Сертификация – будем ли мы проверять тех, кого допустим к системе, в каких случаях, какие роли.
-
Легитимность – кто вообще имеет право работать в системе.
-
Открытые, закрытые данные – не забываем о госзаказах.
-
Модернизация технической базы.
-
Это то, что надо не забыть. Конечно, когда мы эти пункты прорабатываем, мы уже понимаем, что надо спросить, какой объем, какие сроки, какие скорости. Но здесь я выделила отдельно, чтобы целенаправленно показать. И, конечно, это требует отдельного разговора, отдельного рассмотрения.
Мы пробежали по всем пунктам – что важно не забыть. Потом все это попадет в контракт, если контракт есть.
А если контракта нет, это все равно нужно, чтобы подготовить базу, на которой будем работать, даже если это внутренняя разработка для какого-то предприятия или организации. Нужно же, чтобы служба безопасности свои инструкции поправила, а бизнес обновил регламенты – добавил в них особенности развертывания и рекомендации к сопровождению.
И самое главное – как обеспечить приемку.
С кем мы согласовываем наши решения? Разработка тоже должна согласовать, что это реализуемо. Сопровождение тоже должно понимать, что они будут сопровождать. Поэтому согласовывать должен тот, кто будет разрабатывать, эксплуатировать, принимать.
С приемкой есть сложности, потому что очень часто бывает так, что требования нам ставил один, а подписывает другой. Поэтому сразу прописывайте, кто будет согласовывать. На предпроекте очень важно, ведь это не только предпроектные документы, но и потом, в конце мы по этим документам приемку будем сдавать систему, а заказчик – принимать.
Важно, что мы прямо в предпроектных документах пишем пофамильно – кто согласовывает и кто принимает.
Если фамилия меняется, мы идем и договариваемся: «Ты тоже так считаешь? Если ты тоже так считаешь, как тот, кто был до тебя, пожалуйста, распишись. А если ты так не считаешь, то, пожалуйста, дай замечания, мы будем думать, что с ними делать».
Это очень важная вещь для успешной сдачи проекта.
Здесь шаги, чтобы свериться и не забывать.
И литература:
-
IIBA «BABOK Guide v3. Руководство к своду знаний по бизнес-анализу»
-
К. Вигерс, Дж. Битти «Разработка требований к программному обеспечению»
-
Э. Халл, К. Джексон, Д. Дик «Инженерия требований»
-
А. Коберн «Современные методы описания функциональных требований к системам»
-
Ivar Jacobson «The Essence of Software Engineering»
-
Ivar Jacobson «Kill All Methods – Free the Practices», SECR-2017
-
Анатолий Левенчук «Системное мышление»
*************
Статья написана по итогам теоретической части мастер-класса, проведенного на конференции Анализ & Управление в ИТ-проектах 2023. Практическую часть мастер-класса рекомендуем посмотреть в видеоформате (видео)
