Разработка… она как наркотик — систему пишут, пишут, ведь «прет» же. А потом, вдруг оказывается — «алименты» нужно платить. А любое изменение системы влечет гору ошибок. А ведь еще в начале прошлого века великий Курт Гёдель предвидел это и строго доказал, что даже в арифметике у нас не хватает ума, чтобы выразить все ее законы без противоречий. А в программировании и подавно — мы начнем наступать себе на ноги и запутываться. Что, в общем-то, и происходит: то ноутбук ночью включается и перезагружается, то мобильные приложения сыпят ошибками так, что они из кармана начинают выпадать и разбегаться, бранясь и попискивая, по полу.
А как вам модные нынче бета-версии всего и вся? Cкоро самолеты начнут выходить в альфа-бета версиях, похоже.
Но ведь можно же программировать без ошибок, чтобы душа радовалась и пиво попить с клиентом было не только приятно, но и безопасно!
В этом цикле публикаций на тему разных аспектов разработки ПО я постараюсь сформировать минималистичный набор ценностей и правил, которые, во-первых, помещаются в голове у среднего человека, а, во-вторых, обычно, позволяют… побеждать с наименьшими затратами и сроками. Сегодня откровенно поговорим о сборе требований к программной системе.
Театр, всюду театр. А ведь отрасль разработки программного обеспечения несомненно выиграет, если все участники процесса будут говорить правду, во-первых, себе, а, во-вторых — никто не будет поддерживать бессистемные эмоции и служение Ктулху вокруг.
За примерами далеко ходить не нужно — модели открытой разработки и их успешность (не обязательно некоммерческие) убедительно показывают:
- ясность, открытость, смелость
- обсуждение с сообществом и клиентом
- быстрое выявление и решение проблем
а также максимально справедливые коммуникации, основанные на доверии и уважении друг ко другу — ведут программное решение, например, веб-сайт, к успеху.
Мир активно меняется. Горизонтальные коммуникации происходят со скоростью света и если мы не научимся использовать это новое оружие — точно проиграем. Но вначале немного оглянемся вокруг.
Откуда же взялась «священные войны» в программировании?
Все просто. Достаточно вспомнить школьный курс геометрии. Научное понимание мира, в котором мы живем, базируется на… вере в «непреложные истины» = аксиомы, например в то, что «параллельные прямые не пересекаются» или в количество простых чисел в диапазоне (хотя это, правда, теорема, но она, собака, работает, но никто не понимает почему).
Доказать аксиому — невозможно, остается только верить, что она работает всегда. А слетать к горизонту событий Черной Дыры и проверить — мы пока не можем. И объяснить, почему между фотонами взаимодействие передается гораздо быстрее скорости света, тоже.
Многочисленные научные теории используют аксиомы для логического вывода теорем и так далее и так рождаются толстые книжки с определенным сроком гарантии. В результате, и это уже не смешно, Великая теорема Ферма была доказана в девяностых так, что понять доказательство может только горстка избранных с отличным уровнем специального образования, способных перелопатить несколько десятков страниц убористого текста с формулами под микроскопом :-) Именно поэтому до сих продолжаются поиски «настоящего», простого и красивого доказательства.
Даже в, казалось бы, ну что может быть проще, арифметике, неоднократно принимались попытки привести аксиомы в порядок — но воз и ныне там…
Аналогично, языки программирования и технологии, на которых мы с вами создаем веб-сайты, мобильные приложения и информационные системы, по сути, также представляют собой набор аксиом или точек отсчета, в которые также нужно сначала «поверить» и на которых строится фундамент технологии, но доказать, что они верные — нельзя (хотя, иногда, все же можно: попробуйте написать веб-сайт на C++ и увидите, сколько потеряете времени и денег).
Например, в мире Java/C# и других авторитетных и солидных, современных, строго типизированных языках со статической типизацией нужно только один раз взять и «поверить», что мир состоит из психопатов, склонных к насилию и потери самоидентификации, и поэтому «набор аксиом» делает все, чтобы защитить разработчика не только от коллег, но и от него же самого (конечно, я шучу).
В результате получаются программные системы, которые создаются долго, из железа и бетона, которые затем покрываются сотнями автотестов, а в результате может оказаться, что к моменту окончания строительства бизнес-требования давно устарели, ядерное оружие запретили и бункер с 100-метровыми стенами — пойдет сразу в музей. Но нередко такое восприятие мира — работает хорошо, например в разработке узко-специализированных систем или там, где цена ошибки — очень высока (банки и т.п.).
В мире динамических языков со строгой/нестрогой типизацией (PHP, JavaScript, Python, Ruby) набор аксиом совершенно, от слова «совсем», другой:
- нас окружают умные люди, которые пишут сразу правильно и аккуратно
- мания преследования (изменение типа переменной ниже по листингу, доступ к скрытым членам класса другим разработчиком со «злым» умыслом, обязательно впереди потребуется глубокий рефакторинг кода и т.п.) — заболевание, от которого нужно постараться побыстрее вылечиться
- железо дешевеет, поэтому компилировать программу нужно лишь кусочками и то, при необходимости
- чем больше кода, тем больше ошибок, поэтому код должен сразу хорошо читаться, быть ясным, кратким и сексуальным
В мире функциональных языков, типа Haskell/OCaml, требуется поверить в то, что:
- любую задачу можно выразить функцией
- переменные, циклы и мутабельность — ведет к ошибкам (это так на самом деле)
- программирование — для избранных и склонных к аналитическому
В результате, вместо простых скриптов-костылей «сделал, проверил, решил и забыл» на рабочем месте начинается настоящая научная деятельность и поиски «функции Бога» — очень ведь интересно выразить веб-сайт… набором функций без переменных, вау!
Я, конечно, преувеличиваю, но нет дыма без огня. Хотя в некоторых задачах этот подход работает просто отлично и лучшего подхода не придумали.
«Крестовые походы» в управлении программными проектами
В области управления проектами ситуация еще больше покрыта псевдонаучным мраком. А причина хорошо известна: очевидное, лежащее на поверхности, простое и лаконичное решение в лоб:
- понять, чего хочет клиент
- привлечь специалистов и оценить объем работ
- написать код
в реальности, почему-то, не работает :-)
Опытные участники проектных команд хорошо знают, что заказчик часто, банально, не знает, чего хочет, ибо переполнен эмоциями, а задачки по математики в школе — списывал, что привело со временем к частичному «атрофированию части мозга», отвечающей за логически непротиворечивое выражение своих мыслей. Имея перед собой поэтические опусы, рисунки губной помадой и записи гитарных аккордов, вместо технических требований к веб-сайту, специалисты, плача, чтобы не засмеяться от бессилия, увеличивают оценки объема работ на порядок, вводят налог за неадекватность и так далее.
В этих условиях отсутствия строгой логики и желания, простите, использовать голову по назначению, как на дрожжах, возникают страшные ненаучные злоупотребления в стиле астрологии/нумерологии/праноядения и гадания на кофейной гуще.
Злоупотребления, обычно, активно эксплуатируются очень уверенными в себе людьми, умеющими хорошо убеждать, которые никогда в руках «кода» не держали (да, я про неправильно приготовленный Agile).
Говорят, в некоторых командах перед спринтом даже, особо ярые поклонники, принуждают нас, инженеров, к, простите, уринотерапии :-) Однако сами эти «практики», нередко создаются очень опытными разработчиками, которые, как никто другой, могут ими правильно пользоваться.
Мне тут очень нравится аналогия с нунчаками — вроде нехитрое оружие, но вот правильно воспользоваться им могут единицы, а большинство получают травму, простите, сами знаете чего.
Еще один миф — взаимозаменяемость
Иногда нас пытаются убедить во взаимозаменяемости инженеров. Известно, чтобы хорошо и глубоко разобраться в программной технологии, нужно перечитать немало книг, прослушать с десяток курсов, решить несколько сотен задачек и принять участие в пятерке программных проектов, из которых, минимум один, пришел к финишу. Дальше — начинается опыт, который лет через 5, как минимум, делает из кодера — Специалиста.
Обычно, постоянно работая над проектами, разработчик хорошо владеет одним-двум языками программирования и смежными технологиями. Успех и профессиональный рост инженера кроется именно в его узкой специализации, т.к. помимо самих языков необходимо глубоко копаться в системных библиотеках, которых, часто, очень много и документация к ним очень обширная.
Проблема в том, что сейчас, почему-то, модно книжки не читать — а гуглить и списывать, не включая , параллельно ментально мастурбируя в социальных сетях и уведомлениях смартфона.
Найти настоящего специалиста, который системно учится снизу вверх, медленно, но верно, устраняя пробелы в собственных знаниях — становится все сложнее и сложнее. Рынок, к сожалению, наполнен «самоучками» с… «балованными ручками».
Что же делать? Рекомендуемые ценности для выживания
Во-первых, не нужно отчаиваться и очень важно не предаваться эмоциям. Необходимо четко понимать, что разработка — это, прежде всего, строгая математика (обычно на уровне школы) и логика с метриками, в которой нужно, используя тервер и интуицию, заниматься приоритетными рисками и «мочить» боссов еще в младенчестве.
Играли раньше в онлайн-игры и хорошо получалось — вот и продолжайте, только вместо боссов у вас будут программные проекты, а вместо багов — зерги!
Всегда можно и нужно трезво управлять рискам и, по опыту, если делать «системно и научно», программный проект либо взлетит в оговоренные сроки, либо быстро станет понятно, почему ракета не заводится и в чем/ком, конкретно, проблема.
С учетом вышесказанного рекомендуется как можно раньше начать придерживаться нижеперечисленных ценностей близко-научно-эмпирического подхода, которые тесно пересекаются с широко известным гимном здравому смыслу — "дзеном питона" и "agile-манифестом":
- Искать самое простое и ясное решение
- Чем яснее, тем правильнее
- Стало сложно — значит где-то косяк и нужно продолжать дальше искать
- Высокоумие — от неуверенности или трудного детства
- Способности человеческого — ограничены, особенно под действием гормонов, а в некоторые периоды даже слишком
- От алкоголя и курения — мы интенсивно тупеем
- Мы — склонны быстро забывать даже то, в чем хорошо разбирались и даже совсем недавно
- Стремиться к максимальной прозрачности и открытости
- Уважать друг друга
- Поощрять максимально быстрое всплытие и обсуждение проблем в как можно более широком кругу — идеально сразу во всеми
- Делать выводы и не наступать на грабли 3.14 раза подряд :-)
Рекомендации по сбору требований
Узнав некоторые секреты и особенности тенденций в разработке программного обеспечения, уверенно двинемся дальше — научимся правильно собирать требования к системе.
Способен ли заказчик — думать в принципе?
Ничего смешного — вполне таки штатная ситуация. Да и заказчик в этом контексте — понятие собирательное. Прежде всего постарайтесь оценить уровень логического и способности концентрироваться представителей клиента. С кем вы собираетесь работать и кто вам будет помогать? Возможные варианты:
- Политическая тусовка. Нужно сделать, к примеру, веб-проект к дате потому-что кто-то чего-то хочет/обещал… Требования размыты, детали не знает никто, а кто знал — давно уволится. Проект пилила команда, которая ушла и понять, что они напилили — практически невозможно. На стенах — высохшие от, возможно, суицида ведущего программиста. Код — плохой и хрупкий, пахнет так, что глаза режет. Часто в такой ситуации пытаются найти, простите, «сакральную жертву», на которую можно будет свалить следующие полгода и… начать искать новую. Ощущение страха, депресняка и подавления открытости процесса с примесью крови на губах. Вероятность вовремя сделать программное решение, правда небольшая, тут все таки имеется — если делать заново на готовом фреймворке с готовой документацией. Обычно только так и никак иначе.
- Вы общаетесь с представителями клиента и понимаете, что людям искренне трудно непротиворечиво/формально излагать собственные мысли, которые путаются после третьего предложения, повторяются и ходят по кругу. Через 15 минут диалога начинаются жалобы на головную боль. Слышится смех, атмосфера тусовки, селфи, жизнь удалась… Но желания, в целом, понятны и искренние — нужно просто чуточку помочь их оформить строго. Вероятность взлететь тут обычно повыше, чем в п.1, но опять таки, обычно помогает использование как можно более готового, коробочного решения с готовой документацией и типовыми сценариями.
- Клиент хорошо понимает, чего хочет и пытается логически непротиворечиво излагать собственные мысли и желания. В этом ему помогает аналитик, который не путается, излагая мысли менеджмента и выдавая их за свои. В команде клиента также есть минимум один эксперт в его предметной области (забавно, но это довольно таки редкая ситуация). В этом случае вероятность помочь и программно решить задачу — весьма высока. Тут можно ввязываться в проектирование, совместное обсуждение глоссария, модели объектов, модели данных, потоков данных, сценариев нагрузочного тестирования. Скорее всего собрать требования вы сможете и в разумные сроки.
Еще важный момент тут — выстроить как можно более доверительные отношения с клиентом, показать свою открытость и желание помочь заказчику ясно выразить свои мысли. Нередко помогает некий тренинг, на котором представителям заказчика объясняют, как работать со следующими инструментами сбора требований:
- Глоссарий, в котором записывают общие формулировки
- Логическая модель данных, в которой между элементами глоссария вводят строгие отношения множественности (один к одному, один ко многим, многие ко многим)
- Роли и цепочки использования, в которых показывают, кто пользуется системой и как
Тревожные сигналы, которые будут свидетельствовать о надвигающихся проблемах в сборе требований:
- представители заказчика переводят «стрелки» друг на друга и не могут двух слов связать, при этом очень много эмоций — тут рекомендуется как можно быстрее эскалировать проблему и выходить на уровень выше — иначе вас, как «сакральную жертву», принесут в дар культу бардака и выхода на пенсию/в декрет. Работать в таких условиях по Agile — крайне опасно, лучше писать строгое ТЗ и двигаться небольшими этапами
- представители клиента отвечают в стиле: ой, голова болит, а ты же умный, «программист», вот и разбирайся. Тут нужно требовать найти эксперта в предметной области, несущего ответственность за ответы от лица заказчика и как можно быстрее. Или см. пункт выше.
- о проблемах (нечитаемый код, отсутствие документации к основным бизнес-процессам) предпочитают не говорить, т.к. деньги были потрачены, должности получены, премии озвучены и проговаривание рисков может привести к интенсивной прочистке кадрового состава (все же все «понимают», а тут инженеры бочку катят) — тут сложно дать совет, действуйте по фактической погоде
В перечисленных выше клинических случаях, опять таки, хорошо помогает разработка на базе готового коробочного/облачного решения с уже готовой документацией. Такой подход на порядки снизит риски внезапных изменений курса на 180 градусов. Но гарантий уже меньше.
В случае же адекватного подхода со стороны клиента, желания учиться и понимать вас, искреннего желания запустить проект в срок и развивать дальше, неплохо помогает одновременное использование нескольких технологических платформ. Проектировать уже не страшно — вы чувствуете, что ответственность за сбор требований клиент разделяет с вами на 100% и можно попытаться сделать ему хорошо. Вы — страхуете друг друга и вместе боретесь со сложностью:
- веб-сайт на PHP с фреймворком, коробочным решением
- предиктивная аналитика на Python
- мобильное приложение либо на единой платформе, работающей везде, либо пишем под каждое устройство
Не тяните время!
Если 2-3 недели, в крайнем случае месяц-полтора, не проходит ощущение, что вы участвуете в спектакле «поболтаем с умными видом и потянем время и свалим все на кого-нибудь», дергайте стоп-кран, поджигайте поезд и громко кричите в рупор: «расходимся по домам, дети! представление окончено».
Если серьезно, собирайте встречу с менеджментом клиента и настаивайте на включении в проектную команду адекватных сотрудников, понимающих в деталях, как устроен бизнес и способных ответить на строго поставленные вопросы инженеров. Или увольняйтесь — иногда это самый правильный шаг: сохраните лицо и вырастете как специалист.
Чеклист
В результате, можно считать процесс сбора требований успешным и имеет смысл двигаться дальше, если, совместно с заказчиком, вы смогли подготовить в течении пары-тройки недель следующие артефакты:
- Глоссарий, в котором перечислены 50-150 терминов предметной области
- Логическая модель данных со связями терминов из глоссария
- Сценарии использования с терминами из глоссария
- Для сложных алгоритмов — блок-схемы или диаграммы активности UML
- Интерфейсы программной системы, логически не противоречащие вышеперечисленным пунктам
- Вы определились с набором аксиом, описывающих ваше отношение к миру = выбрали программную технологию. Тут многих, по причине любви к творчеству, тянет к садо-мазохизму и желанию заново изобрести велосипеды — боритесь с этим желанием. Определитесь: или весь мир полон подвохов и психопатов и делаем бункер, выдерживающий атаку НЛО, или разработчики искренне хотят вам помочь. Лучшая технология и набор аксиом: развитый фреймворк или готовое коробочное решение — риски не взлететь снизятся на порядки (по опыту, взлетает 95% и выше проектов)
- Вы пропустили программную систему через заказчика, себя, через свой и нигде не осталось мутных мест или эмоциональной жижи. Если такие потенциально протухающие места имеются (а это, как правило, происходит всегда) — включите их в план управления рисками и озвучивайте на каждом проектном совещании. И ждите, что вас подставят и обязательно спросят, как же вы это пропустили
Если вышеперечисленных артефактов за указанный период собрать не удалось, а имеются лишь закрывающие пятую точку бумажки типа расплывчатого ТЗ «губной помадой», сотрудничать аналитики друг с другом не собираются, экспертов в предметной области на стороне клиента не предвидится, проблемы замалчиваются и царит атмосфера показухи и «только хорошие новости» — собирайте вещи: взлететь скорее всего вам не дадут, исследование Луны откладывается не неопределенное время и вы попали в театральное представление «потянем время еще чуть чуть пока не разгонят».
Для достижения настоящего успеха очень, очень важно по-настоящему любить программные системы, отдаваться сбору требований и проектированию на полную катушку, желать ракетам скорейшего старта, пить пиво с заказчиком, доверять друг другу и постоянно повторять про себя слова Эдсгера Дейкстры: «простота — залог надежности»!
С Наступающим всех и искренне желаю удачи в реализации программных проектов.
Автор: AlexSerbul
