Сбор требований к программному проекту — без купюр

Разработка… она как наркотик — систему пишут, пишут, ведь «прет» же. А потом, вдруг оказывается — «алименты» нужно платить. А любое изменение системы влечет гору ошибок. А ведь еще в начале прошлого века великий Курт Гёдель ^[1] предвидел это и строго доказал ^[2], что даже в арифметике у нас не хватает ума, чтобы выразить все ее законы без противоречий. А в программировании и подавно — мы начнем наступать себе на ноги и запутываться. Что, в общем-то, и происходит: то ноутбук ночью включается и перезагружается, то мобильные приложения сыпят ошибками так, что они из кармана начинают выпадать и разбегаться, бранясь и попискивая, по полу.

А как вам модные нынче бета-версии всего и вся? Cкоро самолеты начнут выходить в альфа-бета версиях, похоже.

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

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

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

За примерами далеко ходить не нужно — модели открытой разработки и их успешность (не обязательно некоммерческие) убедительно показывают:

• ясность, открытость, смелость
• обсуждение с сообществом и клиентом
• быстрое выявление и решение проблем

а также максимально справедливые коммуникации, основанные на доверии и уважении друг ко другу — ведут программное решение, например, веб-сайт, к успеху.

Мир активно меняется. Горизонтальные коммуникации происходят со скоростью света и если мы не научимся использовать это новое оружие — точно проиграем. Но вначале немного оглянемся вокруг.

Откуда же взялась «священные войны» в программировании?

Все просто. Достаточно вспомнить школьный курс геометрии. Научное понимание мира, в котором мы живем, базируется на… вере в «непреложные истины» = аксиомы, например в то, что «параллельные прямые не пересекаются» или в количество простых чисел в диапазоне ^[3] (хотя это, правда, теорема, но она, собака, работает, но никто не понимает почему).

Доказать аксиому — невозможно, остается только верить, что она работает всегда. А слетать к горизонту событий Черной Дыры и проверить — мы пока не можем. И объяснить, почему между фотонами взаимодействие передается гораздо быстрее скорости света, тоже ^[4].

Многочисленные научные теории используют аксиомы для логического вывода теорем и так далее и так рождаются толстые книжки с определенным сроком гарантии. В результате, и это уже не смешно, Великая теорема Ферма была доказана в девяностых так ^[5], что понять доказательство может только горстка избранных с отличным уровнем специального образования, способных перелопатить несколько десятков страниц убористого текста с формулами под микроскопом :-) Именно поэтому до сих продолжаются поиски «настоящего», простого и красивого доказательства.

Даже в, казалось бы, ну что может быть проще, арифметике, неоднократно принимались попытки привести аксиомы в порядок — но воз и ныне там…

Аналогично, языки программирования и технологии, на которых мы с вами создаем веб-сайты, мобильные приложения и информационные системы, по сути, также представляют собой набор аксиом или точек отсчета, в которые также нужно сначала «поверить» и на которых строится фундамент технологии, но доказать, что они верные — нельзя (хотя, иногда, все же можно: попробуйте написать веб-сайт на C++ и увидите, сколько потеряете времени и денег).

Например, в мире Java/C# и других авторитетных и солидных, современных, строго типизированных языках со статической типизацией нужно только один раз взять и «поверить», что мир состоит из психопатов, склонных к насилию и потери самоидентификации, и поэтому «набор аксиом» делает все, чтобы защитить разработчика не только от коллег, но и от него же самого (конечно, я шучу).

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

В мире динамических языков со строгой/нестрогой типизацией (PHP, JavaScript, Python, Ruby) набор аксиом совершенно, от слова «совсем», другой:

• нас окружают умные люди, которые пишут сразу правильно и аккуратно
• мания преследования (изменение типа переменной ниже по листингу, доступ к скрытым членам класса другим разработчиком со «злым» умыслом, обязательно впереди потребуется глубокий рефакторинг кода и т.п.) — заболевание, от которого нужно постараться побыстрее вылечиться
• железо дешевеет, поэтому компилировать программу нужно лишь кусочками и то, при необходимости ^[6]
• чем больше кода, тем больше ошибок, поэтому код должен сразу хорошо читаться, быть ясным, кратким и сексуальным

В мире функциональных языков, типа Haskell/OCaml, требуется поверить в то, что:

• любую задачу можно выразить функцией
• переменные, циклы и мутабельность — ведет к ошибкам (это так на самом деле)
• программирование — для избранных и склонных к аналитическому мышлению ^[7]

В результате, вместо простых скриптов-костылей «сделал, проверил, решил и забыл» на рабочем месте начинается настоящая научная деятельность и поиски «функции Бога» — очень ведь интересно выразить веб-сайт… набором функций без переменных, вау!

Я, конечно, преувеличиваю, но нет дыма без огня. Хотя в некоторых задачах этот подход работает просто отлично ^[8] и лучшего подхода не придумали ^[9].

«Крестовые походы» в управлении программными проектами

В области управления проектами ситуация еще больше покрыта псевдонаучным мраком. А причина хорошо известна: очевидное, лежащее на поверхности, простое и лаконичное решение в лоб:

• понять, чего хочет клиент
• привлечь специалистов и оценить объем работ
• написать код

в реальности, почему-то, не работает :-)

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

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

Злоупотребления, обычно, активно эксплуатируются очень уверенными в себе людьми, умеющими хорошо убеждать, которые никогда в руках «кода» не держали (да, я про неправильно приготовленный Agile).

Говорят, в некоторых командах перед спринтом даже, особо ярые поклонники, принуждают нас, инженеров, к, простите, уринотерапии :-) Однако сами эти «практики», нередко создаются ^[10] очень опытными разработчиками, которые, как никто другой, могут ими правильно пользоваться.

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

Еще один миф — взаимозаменяемость

Иногда нас пытаются убедить во взаимозаменяемости инженеров ^[11]. Известно, чтобы хорошо и глубоко разобраться в программной технологии, нужно перечитать немало книг, прослушать с десяток курсов ^[12], решить несколько сотен задачек и принять участие в пятерке программных проектов, из которых, минимум один, пришел к финишу. Дальше — начинается опыт, который лет через 5, как минимум, делает из кодера — Специалиста.

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

Проблема в том, что сейчас, почему-то, модно книжки не читать — а гуглить и списывать, не включая мозг ^[7], параллельно ментально мастурбируя в социальных сетях и уведомлениях смартфона.

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

Что же делать? Рекомендуемые ценности для выживания

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

Играли раньше в онлайн-игры и хорошо получалось — вот и продолжайте, только вместо боссов у вас будут программные проекты, а вместо багов — зерги!

Всегда можно и нужно трезво управлять рискам и, по опыту, если делать «системно и научно», программный проект либо взлетит в оговоренные сроки, либо быстро станет понятно, почему ракета не заводится и в чем/ком, конкретно, проблема.

С учетом вышесказанного рекомендуется как можно раньше начать придерживаться нижеперечисленных ценностей близко-научно-эмпирического подхода, которые тесно пересекаются с широко известным гимном здравому смыслу — "дзеном питона ^[13]" и "agile-манифестом ^[14]":

1. Искать самое простое и ясное решение
2. Чем яснее, тем правильнее
3. Стало сложно — значит где-то косяк и нужно продолжать дальше искать
4. Высокоумие — от неуверенности или трудного детства
5. Способности человеческого мозга ^[7] — ограничены, особенно под действием гормонов, а в некоторые периоды даже слишком
6. От алкоголя и курения — мы интенсивно тупеем
7. Мы — склонны быстро забывать даже то, в чем хорошо разбирались и даже совсем недавно
8. Стремиться к максимальной прозрачности и открытости
9. Уважать друг друга
10. Поощрять максимально быстрое всплытие и обсуждение проблем в как можно более широком кругу — идеально сразу во всеми
11. Делать выводы и не наступать на грабли 3.14 раза подряд :-)

Рекомендации по сбору требований

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

Способен ли заказчик — думать в принципе?

Ничего смешного — вполне таки штатная ситуация. Да и заказчик в этом контексте — понятие собирательное. Прежде всего постарайтесь оценить уровень логического мышления ^[7] и способности концентрироваться представителей клиента. С кем вы собираетесь работать и кто вам будет помогать? Возможные варианты:

1. Политическая тусовка. Нужно сделать, к примеру, веб-проект к дате потому-что кто-то чего-то хочет/обещал… Требования размыты, детали не знает никто, а кто знал — давно уволится. Проект пилила команда, которая ушла и понять, что они напилили — практически невозможно. На стенах — высохшие мозги ^[7] от, возможно, суицида ведущего программиста. Код — плохой и хрупкий, пахнет так, что глаза режет. Часто в такой ситуации пытаются найти, простите, «сакральную жертву», на которую можно будет свалить следующие полгода и… начать искать новую. Ощущение страха, депресняка и подавления открытости процесса с примесью крови на губах. Вероятность вовремя сделать программное решение, правда небольшая, тут все таки имеется — если делать заново на готовом фреймворке с готовой документацией. Обычно только так и никак иначе.
2. Вы общаетесь с представителями клиента и понимаете, что людям искренне трудно непротиворечиво/формально излагать собственные мысли, которые путаются после третьего предложения, повторяются и ходят по кругу. Через 15 минут диалога начинаются жалобы на головную боль. Слышится смех, атмосфера тусовки, селфи, жизнь удалась… Но желания, в целом, понятны и искренние — нужно просто чуточку помочь их оформить строго. Вероятность взлететь тут обычно повыше, чем в п.1, но опять таки, обычно помогает использование как можно более готового, коробочного решения с готовой документацией и типовыми сценариями.
3. Клиент хорошо понимает, чего хочет и пытается логически непротиворечиво излагать собственные мысли и желания. В этом ему помогает аналитик, который не путается, излагая мысли менеджмента и выдавая их за свои. В команде клиента также есть минимум один эксперт в его предметной области (забавно, но это довольно таки редкая ситуация). В этом случае вероятность помочь и программно решить задачу — весьма высока. Тут можно ввязываться в проектирование, совместное обсуждение глоссария, модели объектов, модели данных, потоков данных, сценариев нагрузочного тестирования. Скорее всего собрать требования вы сможете и в разумные сроки.

Еще важный момент тут — выстроить как можно более доверительные отношения с клиентом, показать свою открытость и желание помочь заказчику ясно выразить свои мысли. Нередко помогает некий тренинг, на котором представителям заказчика объясняют, как работать со следующими инструментами сбора требований:

• Глоссарий, в котором записывают общие формулировки
• Логическая модель данных, в которой между элементами глоссария вводят строгие отношения множественности (один к одному, один ко многим, многие ко многим)
• Роли и цепочки использования, в которых показывают, кто пользуется системой и как

Тревожные сигналы, которые будут свидетельствовать о надвигающихся проблемах в сборе требований:

• представители заказчика переводят «стрелки» друг на друга и не могут двух слов связать, при этом очень много эмоций — тут рекомендуется как можно быстрее эскалировать проблему и выходить на уровень выше — иначе вас, как «сакральную жертву», принесут в дар культу бардака и выхода на пенсию/в декрет. Работать в таких условиях по Agile — крайне опасно, лучше писать строгое ТЗ и двигаться небольшими этапами
• представители клиента отвечают в стиле: ой, голова болит, а ты же умный, «программист», вот и разбирайся. Тут нужно требовать найти эксперта в предметной области, несущего ответственность за ответы от лица заказчика и как можно быстрее. Или см. пункт выше.
• о проблемах (нечитаемый код, отсутствие документации к основным бизнес-процессам) предпочитают не говорить, т.к. деньги были потрачены, должности получены, премии озвучены и проговаривание рисков может привести к интенсивной прочистке кадрового состава (все же все «понимают», а тут инженеры бочку катят) — тут сложно дать совет, действуйте по фактической погоде

В перечисленных выше клинических случаях, опять таки, хорошо помогает разработка на базе готового коробочного/облачного решения с уже готовой документацией. Такой подход на порядки снизит риски внезапных изменений курса на 180 градусов. Но гарантий уже меньше.

В случае же адекватного подхода со стороны клиента, желания учиться и понимать вас, искреннего желания запустить проект в срок и развивать дальше, неплохо помогает одновременное использование нескольких технологических платформ. Проектировать уже не страшно — вы чувствуете, что ответственность за сбор требований клиент разделяет с вами на 100% и можно попытаться сделать ему хорошо. Вы — страхуете друг друга и вместе боретесь со сложностью:

• веб-сайт на PHP с фреймворком, коробочным решением
• предиктивная аналитика на Python
• мобильное приложение либо на единой платформе ^[15], работающей везде, либо пишем под каждое устройство

Не тяните время!

Если 2-3 недели, в крайнем случае месяц-полтора, не проходит ощущение, что вы участвуете в спектакле «поболтаем с умными видом и потянем время и свалим все на кого-нибудь», дергайте стоп-кран, поджигайте поезд и громко кричите в рупор: «расходимся по домам, дети! представление окончено».

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

Чеклист

В результате, можно считать процесс сбора требований успешным и имеет смысл двигаться дальше, если, совместно с заказчиком, вы смогли подготовить в течении пары-тройки недель следующие артефакты:

1. Глоссарий, в котором перечислены 50-150 терминов предметной области
2. Логическая модель данных со связями терминов из глоссария
3. Сценарии использования с терминами из глоссария
4. Для сложных алгоритмов — блок-схемы или диаграммы активности UML
5. Интерфейсы программной системы, логически не противоречащие вышеперечисленным пунктам
6. Вы определились с набором аксиом, описывающих ваше отношение к миру = выбрали программную технологию. Тут многих, по причине любви к творчеству, тянет к садо-мазохизму и желанию заново изобрести велосипеды — боритесь с этим желанием. Определитесь: или весь мир полон подвохов и психопатов и делаем бункер, выдерживающий атаку НЛО, или разработчики искренне хотят вам помочь. Лучшая технология и набор аксиом: развитый фреймворк или готовое коробочное решение — риски не взлететь снизятся на порядки (по опыту, взлетает 95% и выше проектов)
7. Вы пропустили программную систему через заказчика, себя, через свой мозг ^[7] и нигде не осталось мутных мест или эмоциональной жижи. Если такие потенциально протухающие места имеются (а это, как правило, происходит всегда) — включите их в план управления рисками и озвучивайте на каждом проектном совещании. И ждите, что вас подставят и обязательно спросят, как же вы это пропустили

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

Для достижения настоящего успеха очень, очень важно по-настоящему любить программные системы, отдаваться сбору требований и проектированию на полную катушку, желать ракетам скорейшего старта, пить пиво с заказчиком, доверять друг другу и постоянно повторять про себя слова Эдсгера Дейкстры ^[16]: «простота — залог надежности»!

С Наступающим всех и искренне желаю удачи в реализации программных проектов.

Автор: AlexSerbul

Источник ^[17]