Жизнь замечательных ТЗ
Под катом – слайдкаст и текстовая расшифровка моего выступления на Летнем Аналитическом Фестивале 2010 года в Иваново. Текст немного причёсан для лучшего восприятия при чтении.
А это видеозапись.
Я должен сразу сказать, что хоть я и явлюясь активным участником Сообщества аналитиков, сам я аналитиком никогда не работал, поэтому если буду говорить какие-то очевидные глупости – вы меня поправляйте, я не обижусь. Я проработал шесть лет в государственном научно-испытательном институте, связанном с авиацией, после этого был программистом. Сейчас моя должность – технический директор, и мне приходится выполнять, в том числе, и обязанности аналитика. И в этом докладе я хочу поделиться своим опытом.
Знаете, сейчас часто поднимается тема «Что такое идеальное ТЗ». Это мой вклад в эту копилку: что же нужно сделать, чтобы ТЗ было если не идеальным (написать идеальное ТЗ, конечно, невозможно), то хотя бы могло удовлетворять тех людей, которые будут использовать его в своей работе.
О чём мы поговорим. Вспомним, что такое техническое задание. Все, вроде бы, знают, что это такое, но когда начинаешь копать, а особенно в интернете читать откровения фрилансеров, то начинаешь понимать, что это очень неоднозначное понятие. Поэтому мы очень коротко вспомним, что это и для чего оно вообще нужно в принципе. Потом я хочу представить такую простенькую модель жизненного цикла технического задания, рассмотреть тех людей, которые его используют в своей работе и выяснить, какие интересы они преследуют и как их можно удовлетворить. И, если успеем, рассмотрим некоторые отклонения или аномалии, которые тоже нужно учитывать при разработке технического задания.
Давайте коротко вспомним, зачем нужно ТЗ. Я вас, как аналитиков, попросил бы помочь. Вы можете ответить, для чего вообще нужны технические задания?
Ответы из зала:
— Определить содержание будущего продукта.
— Обозначить цели, зачем вообще создаётся продукт.
— Определить контрактные обязательства.
— В ТЗ мы фиксируем образ продукта, выявленные свойства, которыми должен обладать продукт.
— ТЗ описывает процессы, в соответствии с которыми продукт будет разрабатываться: документирование и так далее, требования к патентной чистоте…
Я слышу здесь отдельные слова из 34 ГОСТа. А кто-нибудь работает по ГОСТ при разработке ТЗ? (поднимают руки несколько человек)
34-й ГОСТ нам прямо говорит, что техническое задание определяет требования к системе, порядок её разработке и порядок приёмки. Это там зафиксировано чуть ли не в первом пункте. Ну вот, собственно, это здесь я и написал. И, об этом тоже говорили, техническое задание – это фактически такой самодостаточный документ. Если что-то пошло не так и, не дай бог, дошло до разбирательства, кто же не прав, то оно, можно сказать, носит статус договора. Сейчас, конечно, ГОСТ, во-первых, не является обязательным, а во-вторых, он был написан достаточно давно и не может описать все возможные нюансы.
Если вы, допустим, почитаете на сайтах веб-студий, для чего нужно ТЗ, то обнаружите, что они, просто не раз наступив уже на грабли, выделяют два основных момента: описать требования к системе (что она должна делать) и, это главные грабли, зафиксировать объём работ.
Мы вспомнили, для чего ТЗ нужно в принципе. Теперь я предлагаю вернуться к жизненному циклу разработки. Все, наверное, изучали, что это такое, но не все понимают, зачем это нужно в практической деятельности. Здесь представлена достаточно простая модель. Не считайте, что это «водопад»: на самом деле, эти квадратики могут не один за другим следовать, а быть размазанными по этапам разработки. Но главное, что есть некоторая последовательность действий, которые разные люди выполняют в процессе разработки. Начинается всё либо с идеи, которая пришла кому-то в голову, либо с осознанной проблемы. После того как эта идея запускается в разработку, мы начинаем оформлять требования к будущему продукту, потом следуют проектирование, реализация, тестирование, сопровождение – привычные всем вещи, на которых я не буду подробно останавливаться. Мы же говорим не жизненном цикле продукта, а о техническом задании.
Как вообще мы работаем с техническим заданием в таком жизненном цикле? Когда только появляется идея, на этом этапе, как правило, разрабатываются концепции, тактико-технические задания – там разные названия есть, но фактически ядро описания будущей системы закладывается на этом этапе. Потом основная часть ТЗ у нас разрабатывается на этапе формирования требований. Когда мы заканчиваем формирование требований, резко уменьшается объём изменений, вносимых в техническое задание. Потом, в процессе разработки, изменения, конечно, тоже могут вноситься. Здесь уже возникают особенности разных моделей и разных проектов. Но, например, ГОСТ нам говорит однозначно, что изменения в ТЗ не допускаются после начала приёмочных испытаний – насколько я помню, там есть такая фраза. В реальной жизни это не так, и эта картинка отображает одну из этих реальностей.
Нижняя часть картинки показывает, как ТЗ используется в процессе разработки. Основные потребители технического задания – это те, кто разрабатывает систему: разработчики, архитекторы, тестировщики… Или вы можете ещё каких-то потребителей сразу мне назвать? Никого не смущает то, что я говорю сейчас? Что вообще не так в этом цикле? Скажите, какой из этапов, представленных этими квадратиками, самый длительный по времени? Сопровождение, конечно же!
Дело в том, что эта модель представляет только точку зрения разработчика. Это этапы, которые существенны для разработчика. А в сером квадратике «Сопровождение» заключаются приёмка, эксплуатация… – в общем, по времени он обычно длится намного дольше, чем собственно разработка системы.
С точки зрения заказчика всё, что мы там нарисовали, – это разработка, один маленький квадратик. А в том, что мы назвали сопровождением, у заказчика в процессе освоения системы возникают свои этапы. Я не претендую на полноту этой модели, здесь представлены простые и очевидные этапы. Когда система разработана, сначала она принимается, потом некоторое время осваивается. Потом она активно используется, параллельно с использованием она развивается, вносятся какие-то изменения, и, в конце концов, когда она устаревает, её заменяют на новую систему.
То, что разработчику кажется основным в жизненном цикле, то для заказчика происходит где-то вдали. А то, что кажется основным заказчику, то для разработчика, как правило, головная боль.
Но мы хотели поговорить о людях. Я хочу предложить рассмотреть некоторые роли, которые возникают на каждом из этих этапов, поставить себя на место этих людей и представить, чего они хотят от ТЗ.
Сначала, когда никакого ТЗ ещё нет, и оно только зарождается, идея о создании системы может возникнуть как у разработчика, так и у заказчика. Системы бывают разные. Некоторые разрабатываются по подряду, когда у заказчика возникла идея, а мы ему готовы её реализовать. Некоторые идеи возникают у самих разработчиков, когда создаются, например, коробочные продукты. Для нас важно, что хотя ТЗ ещё нет, на этом этапе закладывается его ядро. Концепция, vision, или как это ещё называется – это фактически ядро для будущего технического задания.
При формировании требований возникает собственно роль аналитика. На ней мы подробно останавливаться не будем, потому что все вы знаете, чем вам приходится заниматься.
Первый потребитель результатов того, кто разрабатывает ТЗ – это тот, кто обычно называется архитектором. В разных проектах может сначала создаваться архитектура, а может не создаваться, например, если проект маленький. Этот человек может называться по-другому. Здесь важно найти грань между требованиями и особенностями реализации.
Вообще, я очень коротко пройду ту часть, которая относится к разработке, потому что эта часть вам хорошо знакома, и здесь меньше всего вопросов возникает.
Скажите, а у вас вообще программисты ТЗ читают? На самом деле, программист должен быть основным потребителем этой информации – требований к системе. Но, например, по моему опыту, программисты ТЗ читать не любят, хотя в нём содержится очень полезная для них информация. Но программисты обычно трепетно относятся к спецификациям, содержащим технические детали – байтики, битики, форматики. Сейчас я работаю в компании, которая разрабатывает программное обеспечение для терминалов, предназначенных для приёма банковских карт. Там для программиста самое главное – это спецификация взаимодействия терминала с хостом: как послать запрос, получить ответ, правильно проинтерпретировать поля, напечатать чек. Программисты эту спецификацию знают наизусть. А что эта операция в реальной жизни означает – они, бывает, даже не интересуются.
(Комментарии из зала: Это неправильные программисты! Это кодеры, а не разработчики!)
Но есть вариант, как решить эту проблему уже при разработке технического задания. Мы, например, в такую спецификацию непосредственно перед описанием форматов включаем несколько абзацев из ТЗ, то есть описание того, зачем нужна эта операция с точки зрения тех людей, которые будут её использовать. Теперь у программиста нет необходимости брать талмуд ТЗ, который он целиком читать не будет, а в спецификации он эти абзацы прочтёт. А это очень здорово подвинет его к пониманию того, что же действительно ожидается от разрабатываемой системы.
Пойдём дальше. Тестировщики, там где они есть, являются, можно сказать, одними из главных потребителей технического задания на стороне разработчика. Программисты что-то там напрограммировали, а потом тестировщик должен проверить, сооветствует ли это тому, что ожидает заказчик.
Я понимаю, что излагаю это всё на таком поверхностном, примитивном уровне. Но я вам не предлагаю алгоритм: «взяли модель и идите по ней». Я вам предлагаю способ размышления над ТЗ. Чтобы, когда вы пишете ТЗ, вы держали в голове тех людей, которым оно может понадобиться.
Давайте я сразу перейду на следующий слайд. Вот есть тестировщик со стороны разработчика, а есть тестировщик и на стороне заказчика. Если появляется этап приёмки и со стороны заказчика действительно есть такие люди, которые будут систему тестировать (а это бывает не всегда, хотя это крайне полезно), то этих людей я предпочитаю называть испытателями. Я сам был испытателем и испытывал большие военные системы в своё время. В чём отличие испытателя от тестировщика? В том, что испытатель смотрит на систему уже глазами того, кто её будет использовать. Как правило, по роду своей основной деятельности эти люди не тестировщики, а будущие пользователи системы. Или какое-то передаточное звено.
Пример из авиации. Анекдот, хотя говорят, что это реальный случай. В ТЗ было такое требование. Когда лётчик катапультируется, у него перед глазами должна быть табличка, на которой записана краткая последовательность действий. Потому что катапультирование – это всегда ситуация экстренная, лётчик может растеряться, а так он читает «пункт 1, пункт 2, пункт 3» — и успешно катапультируется.
Вот точка зрения тестировщика. Тестировщик проверяет реализацию и говорит: ребята, вы забыли включить первый пункт. Прежде чем катапультироваться, лётчик должен отстрелить фонарь (стекло кабины). Потому что если его не отстрелить, то лётчику придётся пробивать его головой. Головы у лётчиков крепкие, но лишняя нагрузка им ни к чему, поэтому нужно включить пункт «Отстрелить фонарь». Это точка зрения тестировщика: он нашёл в реализации баг, и этот баг исправили.
Точка зрения испытателя. Он говорит: ребята, вы сделали классную табличку. Всё правильно, всё читается, типографика и дизайн вообще идеальные. Одна проблема: когда я отстреливаю фонарь, табличка улетает вместе с ним, потому что она к нему крепится.
Мне рассказывали это как реальный случай. Поняли разницу, да? Между точкой зрения тестировщика, который не знает всех деталей, потому что он не находится в контексте системы полностью, и точкой зрения испытателя, который всё-таки представляет тех, кто будет реально систему использовать.
Каким образом испытатели используют техническое задание? Для них это основной документ. Когда я пришёл служить в испытательный институт, я по программе ввода в строй три месяца только изучал документы. Из этих документов 90% составляли технические задания тех систем, которые разрабатывались раньше и тех, которые нам предстояло испытывать. Там, конечно, всё делалось по ГОСТу, не помню уже номера, и техническое задание действительно было вроде Библии. Материалы технических проектов, эскизных проектов – это уже больше были проблемы того, кто разрабатывает. На основании технического задания разрабатывались методика испытаний, программа испытаний, и по ним потом проводились собственно испытания. Причём всё это делалось ещё до того, как система создана: ТЗ готово – и пошли параллельно два потока. Разработчики разрабатывают систему, а испытатели начинают готовиться к её приёмке. Так было в больших системах, скажем так, военного назначения.
Там, где проекты попроще – скажем, на нынешней работе наши основные клиенты банки или процессинговые центры – у них, конечно, специальных испытателей нет. Но, по опыту работы, у них обязательно найдётся какой-нибудь экселевский файлик, который они когда-то, лет десять назад, использовали. И когда мы к ним со своей системой приходим, они достают его из-под стола и начинают по нему проходить проверку вариантов реального использования системы. Обязательно всегда что-то обнаруживается.
Давайте пойдём дальше. Этап освоения или внедрения. На этом этапе появляется человек, которого я назвал наставником. Это те пионеры, которые первыми начинают использовать вашу систему. Для чего им нужно техническое задание? Вот тут упоминали разработку документации. По нашему опыту, если мы документацию для конечно пользователя разрабатываем сами, она для пользователя оказывается бесполезной.
Пример. Допустим, моя жена осваивает компьютер. Она мне звонит и спрашивает, скажем, что нужно сделать, чтобы выполнить поиск в Яндексе. Я говорю: набираешь запрос, нажимаешь «ввод». А кто из вас знает, где клавиша «ввод» находится на клавиатуре? Такая кнопка была на клавиатурах ЕС ЭВМ двадцать лет назад. А сейчас такой кнопки, оказывается, нет на клавиатуре. Я говорю ей: нажми «Enter». Она понимает, что это не по-русски, но попробуй найди этот Enter. Приходится объяснять, что это справа такая кнопка в форме уголка.
Так вот, примерно на таком языке наши клиенты, вот эти наставники, действительно пишут документацию для пользователей. На терминалах не случайно всегда есть три кнопки, по стандарту обозначенные цветами: жёлтый, красный, зелёный. Зелёный – подтвердить, красный – отменить, жёлтый – коррекция. И инструкция именно так текстом и пишется: «нажмите на зелёную кнопку». Как здесь может использоваться техническое задание? В этом случае особенно хорошо, если техническое задание оформлено с использованием юзкейсов (вариантов использования). Если юзкейс хорошо написан, то его основной сценарий – это фактически готовая инструкция для пользователя. Мы отдаём нашему заказчику, вот этому наставнику, техническое задание (точнее, оно у него уже есть), он меняет там падежи, заменяет слово «enter» на «зелёная кнопка», вставляет фотографии, и у него получается готовая документация. И теперь, когда я пишу ТЗ, особенно с вариантами использования, я всегда это имею в виду.
Эксплуатация. На этом этапе появляется так называемый юзер ушастый. То есть те люди, которые реально используют систему. Читают эти люди техническое задание? Разумеется, нет, они и не должны этого делать. Означает ли это, что их интересы не должны учитываться в техническом задании? Разумеется, должны учитываться, потому что мы для них и разрабатываем систему. В этом смысле очень полезный опыт – это посмотреть, как реально люди её используют.
Пример. Разрабатывали мы для одного банка интерфейс приложения терминала, что характерно, по их требованиям. Требования: провести картой, сверить последние четыре цифры номера карты с тем, что на экране, ввести сумму, ввести ПИН код, если он требуется, посмотреть на экран подтверждения всех данных операции, нажать «ввод» – получается пять-шесть шагов на каждую операцию. Даём им терминал с софтом на пилотный проект. Кассир работает в столовой этого же банка. Для оплаты используются их внутренние платёжные карты. Через день кассир потребовала убрать этот терминал и вернуть старый. Почему? Потому что на обед к ней приходит сразу весь банк, все сто человек, и ей для каждой оплаты нужно только успевать: дёрнуть картой — ввести сумму, дёрнуть картой – ввести сумму. То есть получается, что требования пользователей вроде бы одного и того же заказчика противоречат друг другу в зависимости от того, в какой контекст вы попадаете.
Почему-то при разработке технического задания это не было учтено. Просто тот человек, который отвечал в банке за взаимодействие с нами, думал о том, как максимально застраховаться от рисков. Потому что он до этого работал в управлении контроля за рисками. А оказалось, что в реальной жизни, по крайней мере в пилотном проекте, это совсем не пригодилось.
К чему я это говорил: ещё раз повторю, что крайне полезный опыт – посмотреть, как люди используют вашу систему.
Следующий этап. После того, как систему сдали заказчику и он начал её использовать, у него неизбежно возникают пожелания по её доработке. Либо внешняя среда меняется. В нашем случае, допустим, платёжные системы постоянно изменяют свои требования по защите информации, непрерывно их ужесточают. Нам приходится на это реагировать. Либо у заказчика возникают новые проекты. Например, мы ему реализовали приём карт только для продажи, а потом у него аппетиты растут, и он хочет ещё программу лояльности какую-то для магазинов. Приходится дорабатывать. Это уже доработки. Мы в самом начале сказали, что согласно ГОСТу на этом этапе техническое задание уже не может модифицироваться. Никакие протоколы изменений уже не оформляются, а оформляются уже новые ТЗ – либо частные технические задания, либо ТЗ на доработку, разные варианты есть. Но ГОСТ не панацея и не священное писание, сейчас современные методы учёта требований позволяют всё это делать и в процессе разработки. Но, тем не менее, когда вы пишете ТЗ, вы должны (с моей точки зрения) подумать о том, как система будет развиваться. Как угадать, куда будет развиваться система, и какие новые требования могут возникнуть у заказчика? Угадать это невозможно. А раз угадать невозможно, вы должны позаботиться о том, чтобы ваша методология или ваш подход к разработке позволяли эти изменения в процессе развития системы вносить.
Здесь появляется роль техподдержки. Имеется в виду не та техподдержка, которая отвечает на дурацкие вопросы пользователей. В нашем случае, например, техподдержка – это я, потому что мне присылают запросы наши клиенты. Они должны проходить через меня, оформляться в новые задания программистам, руководство решает, должны клиенты за это платить или нет – это я на примитивном уровне рассказываю. Но вот этот человечек с микрофоном – это фактически тот человек, который принимает запросы на изменения. Его интересы тоже нужно учитывать при разработке ТЗ. У нас, например, техническое задание является документом, который действительно используется на протяжении всей жизни системы. Когда я сам уже не помню, что она должна делать, я заглядываю туда. Если я понимаю, что какое-то требование уже не актуально, как в случае с изменением требований платёжных систем, я вношу изменения прямо в тот документ, который у нас называется техническим заданием.
(В этом месте развернулась небольшая дискуссия)
Ну и последний этап – замена. Когда система устарела, и если вам повезло, и заказчик снова обратился к вам за новой или модернизированной системой, то он переходит в начальный этап идеи, и весь цикл повторяется. Что в этом смысле полезно при разработке технического задания? Здесь такой очень общий опыт: однажды разработав ТЗ и учтя интересы заказчика, вы уже имеете готовый шаблон для разработки ТЗ на новую систему.
Подытожим то, что я уже говорил. То, что я вам предложил – это не универсальная модель, это достаточно примитивный, поверхностный взгляд на разработку, такие самые общие этапы. Не бывает проектов, похожих друг на друга. Везде эти лица возникают разные. Но когда вы разрабатываете документ, вы всегда, как я считаю, должны представить себе тех, кто будет использовать ваши результаты, подумать о том, каким образом они будут их использовать и о том, как вы можете сделать этих людей счастливыми.
Это была сухая теория. Теперь посмотрим на пышное древо жизни. Известно, что в действительности всё не так, как на самом деле, и эти жизненные циклы никогда идеально не работают.
Я опять расскажу несколько примеров из моего опыта. По моему опыту, это бывает очень часто: сначала возникла идея, пошли все этапы, разработано техническое задание, утверждено, а разработка не начинается по разным причинам. Например, когда я работал в лётно-испытательном центре, получилось так, что я туда попал сразу после развала СССР. И технических заданий была целая стопка, а разработка не финансировалась. Что при этом происходит? Год мы готовим программу и методику испытаний, два года, три года и больше – за это время полностью меняется команда и со стороны разработчика, и со стороны заказчика. Я в данном случае, как испытатель, был на стороне заказчика. Для нас это техническое задание как было библией, так и осталось: мы знали, что если система начнёт разрабатываться, то она должна соответствовать этим требованиям. Но поскольку происходит постоянная ротация, люди меняются, когда я пришёл, вся команда уже полностью ушла. И получается, что для меня единственным источником информации о том, что должна делать система, остаётся техническое задание, и больше ничего. И если вы в таких длительных проектах участвуете, то ТЗ должно быть действительно написано очень качественно, я бы сказал даже «по ГОСТу», потому что тут как раз начинает работать водопадный процесс: результаты этапа полностью задокументированы, и потом может любое время пройти, пока вы перейдёте к следующему. Для заказчика это очень хорошо – хорошее ТЗ. Ну тут, наверное, уместно такое благое пожелание, может быть банальное и тривиальное: если пишете техническое задание, то это должен быть тщательно проработанный документ. Учитывайте все эти нюансы, которые на «научном языке» называются рисками.
Вторая аномалия. Приходилось кому-нибудь разрабатывать техническое задание после разработки системы? Всем приходилось? Как хорошо! В данном случае формированием требований занимались тестировщики. Что в реальной жизни бывает: что-то разработано, нужно тестировать, а на соответствие чему проверять – никто не знает. Тогда тестировщики начинают сами формировать требования. Многие через это проходили.
Либо другой вариант. Что-то написали, заказчику поставили, он говорит: всё хорошо, но по нашим правилам вы нам должны предоставить техническое задание, а мы его должны утвердить. И мы начинаем всё это задним числом описывать. Но я не могу здесь дать никаких рекомендаций, просто такие аномалии бывают.
Вот ещё случай. Нормальный жизненный цикл, всё работает, но появляется заинтересованное лицо, о котором вы не подозревали. Рассказываю, как это было в нашем случае. Для одного заказчика начали писать техническое задание, а там всё очень хорошо описывалось в виде вариантов использования. А вы знаете, что варианты использования – это не только требования, это уже фактически база для разработки, для архитектуры. По ним уже можно сидеть и программировать, некоторые даже умудряются их конвертировать в код. И нам пришлось это техническое задание немножечко размыть, потому что мы знали, что у этого заказчика есть другой подрядчик, конкурент. И возможно, что ему уйдёт наше ТЗ как уже готовая основа для разработки. То есть ему аналитики вообще не нужны. Пришлось упростить некоторые варианты использования, оставить только основные сценарии, некоторые выбросить, кое-что описать размытыми словами. Ну вот, такие аномалии тоже бывают: возникает человек, о котором вы не догадывались, и его интересы тоже нужно учитывать, но в своих интересах.
Реплика из зала:
– Делать слабенькое ТЗ в надежде, что оно уйдёт другому – это уже политика. Надо писать настолько хорошее ТЗ, насколько можешь. А если там вмешивается политика, то её нужно решать политическими средствами.
Но мы её политическими средствами и решили. Я написал хорошее ТЗ, а потом его испортил. То есть я поменял роль аналитика на роль менеджера.
Это, собственно, всё. Это даже не выводы, а так, подвести итоги.
По моему опыту, в ГОСТ очень много лишнего. Но, с другой стороны, это очень полезный документ для изучения. Если вы его читаете и над каждой строчкой думаете, почему она там появилась, это очень развивает ваше понимание того, что требуется от технического задания.
Это верно не только для технического задания, а вообще для любого документа: смотрите в будущее, всегда ставьте себя на место тех, кто будет его использовать, и старайтесь учитывать их интересы. Ну и учитывайте то, что я называл аномалиями, и что на самом деле называется рисками. Управление рисками – тоже вещь полезная, в том числе и для аналитиков.
