Те кто занимаются разработкой, наверняка в курсе того, что сейчас появилась мода на составление технического задания и на различные описания того как это делать. Наконец-то появились достойные блоги о проектировании и об управлении проектами. Их, конечно, можно пересчитать по пальцам одной руки, но тем не менее.
В общем, заметны задатки цивилизованных разработок и выхода на новый уровень. С одним «но». У меня иногда возникает дежавю и ассоциация с тем как это было и есть с юзабилити. Когда я читаю про то, как специалисты по юзабилити рассуждают о своей работе, о том, как можно определять в какую точку смотрит пользователь при посещении сайта — все это вызывает чувство надуманности и излишнего усложнения. Даже не буду скрывать, у меня отношение к юзабилити специалистам весьма субъективное и совсем не положительное. Я не понимаю, зачем они нужны. Вся эта отрасль похожа на коммивояжеров, которые продают то, что людям не было нужно до их появления. Мне не понятно как можно производить какие-либо тесты, давать советы, составлять отчеты по уже готовым разработкам со стороны. Это такой вот двойной труд, ведь чтобы вникнуть в проект, необходимо его изучить с нуля. Большее недоверие вызывает то, что у тех, кто занимается юзабилити, проекты почти всегда в разных сферах, с разным предназначением, с разными группами пользователей и т.д. Какими-то невероятными знаниями нужно обладать, чтобы понять каждый проект, понять всю его суть и все его проблемы, масса времени, масса сил. Очень сложно представить, когда исследования по юзабилити могут действительно окупаться. Я, конечно, не говорю про разработку Эйрбаса или новой модели БМВ, речь о программах и сайтах.
Так вот, возвращаясь к тенденции грамотного проектирования сайтов и программ. Несмотря на то, что я всегда был поклонником тщательного подхода и как можно большего сбора информации перед разработкой, составлении ТЗ и всего прочего, я вижу лишь усложнения, о которых пишут в блогах и на сайтах те, кто занимаются освещением темы проектирования. Это усложнение проявляется, например, в том, что идет концентрация на деталях и самом процессе проектирования, а не на общей идеи и результате.
Как бы противоречиво не звучало, но на самом деле техническое задание не решает проблему сроков выполнения и качества конечного результата. Я все больше склоняюсь к тому, что принятые 50% на проектирование от общего времени разработки — это ложный путь. В первую очередь, потому что реальность такова, что скорость и постоянное развитие проекта — это практически основные показатели успеха разработки. Отсюда множество таких вещей, как стоимость разработки, конкурентное преимущество и прочее. В реальном мире на разработку нет времени совсем. Если, что-то делается больше трех месяцев, то значит, кто-то другой это сделает и выпустит быстрее, пусть в виде бета-версии и с ошибками, но выпустит.
В данный момент я занимаюсь разработкой двух программ — это система управления сайтами Legenda и система статистики Impera. При разработке системы статистики есть две основные сложности — это оптимизация и тестирование. Все остальные вещи при опыте программирования не так сложны и достаточно стандартны, поэтому чтобы их спроектировать, не обязательно делать очень подробное ТЗ. Статистика представляется в отчетах и основа почти у всех отчетов схожа по виду и по методам отбора данных. Т.е. фактически проектирование сводится к выработке основной идеи и ряду некоторых особенностей и уникальных отчетов. Поскольку я разрабатываю уже третью версию, то даже такое проектирование мне не требуется, т.к. интерфейс и особенности уже стандартизированы, остается лишь оформить общий вид и привести к общему стилю нововведения. И это должно быть стандартной ситуацией для тех, кто делает не первую свою программу или сайт. Итак, к разработке третьей версии я подошел без подробных описаний и технического задания, все, что у меня было на руках это список задач. Точнее два списка. Первый — это ошибки в предыдущих версиях. Второй — это нововведения, улучшения и список того, что нужно выбросить. Причем второй список составлялся практически полностью в процессе разработки. Задач всего было примерно 200, а перед глазами был список из 20-30, остальные либо отправлялись в «Сделанное», либо еще не были поставлены. Таким образом, на проектирование я совсем не потратил время. Можно, конечно, посчитать время, которое ушло на обдумывание того, как все должно выглядеть и работать, но это тоже не значительно, так как было совмещено с разработкой в реальном времени или во время прогулок по парку, что вряд ли можно назвать рабочим временем.
Как я отметил раньше, значительная часть разработки системы статистики — это оптимизация кода и решений, а также тестирование. И все это не поддается первоначальному проектированию. Можно что-то предсказать, но когда начинаешь работать в реальных условиях и с реальными данными, все идет немножко не так как задумывалось. Поэтому смотришь, как работает, с какой скоростью и если необходимо исправляешь и дорабатываешь.
Разрабатывая систему статистики в реальном времени, я сэкономил 50% времени. Результат и срок работы — меня полностью устроил. Это главный показатель.
Что касается разработки системы управления сайтами то это очевидно более ресурсоемкое и сложное занятие, чем система статистики. Но и в этом случае я изначально решил обойтись минимальным проектированием. Поэтому предварительно я выделил наиболее приоритетные составляющие разработки. Во-первых, это структура базы данных. На это было потрачено достаточно времени и много листов c диаграммами в Visio. Во-вторых, это структура системы, т.е. основа архитектуры. Переводя это в обычный язык — расположение файлов по папкам и их взаимосвязи в настоящем и будущем. Это самые основные вещи в разработке. На них было сосредоточено проектирование. В итоге на руках было две диаграммы — структура базы данных и диаграмма архитектуры проекта. Никаких подробных текстов и описаний. Как пояснение к проекту был составлен список возможностей и список того, что система должна уметь. Это небольшие списки примерно по 50-100 пунктов. Третьей важной составляющей был шаблонизатор, который очень многое предопределил и ввел в правильное русло. На проектирование шабонизатора ушло дня два, причем в это же время он одновременно разрабатывался. Это был хороший пример того, что проектирование это воплощение предыдущего собственного знания и опыта, а также объединение того, что уже сделано другими. Т.е. оставалось лишь объединить свои знания и знания о том, как это сделано в аналогичных шаблонизаторах.
Дальше оставалось только начать разработку и уже в процессе, описывать функциональность каждого модуля или функции. Я это делаю в виде очень кратких тезисов и списка задач, возможностей и т.п. Основное это выделить самое главное, то, что именно характеризует модуль и очень емко записать. Причем такой метод позволяет записать в виде тезисов не только что-то общее, но и детали.
Отказавшись от подробного проектирования системы управления сайтами, я сократил время разработки не несколько месяцев. Конечно, может показаться, что все так быстро и просто, но естественно это не так. Значительное время ушло на придумывание концепции, сбор информации, выработку стандартов. Но это похоже на рождение идеи. Такое время не поддается проектированию и учету. Это уже немного другая область и другие подходы.
Поскольку разработкой я занимался практически в одиночку, по ряду причин, то это накладывает некую обособленность на проектирование и вообще на весь процесс. Но я не думаю, что это настолько важно. Даже более того, это одна из проблем, когда техническое задание и проектирование выполняет один человек. Иногда это выливается в то, что только он один и понимает как и что надо делать. Не раз я сталкивался с тем, что даже вполне серьезные и грамотные технические задания были бесполезны именно по этой причине. Поэтому при работе в команде, я бы обратил внимание, прежде всего на две вещи — это четкое распределение задач и универсализация. Вот задачи действительно должен ставить один человек, и он же должен за весь процесс отвечать. А дальше дело за разработчиками, которые, безусловно, должны иметь опыт и понимать, как делать свою задачу. И здесь излишне подробные описания. Зачем тому, кто уже разработал не одну программу или сделал не один сайт подробные описания основ. Такой человек вполне обязан сам все понимать и знать.
Универсализация элементарно позволяет одному участнику проекта понять работу другого. Делать задачу, ориентируясь на то, как делает свою задачу другой участник. Поэтому скорее важен контакт и общение в команде, чем множество серьезных и подробных описаний. Каждый все равно поймет по-своему написанное, а в общение и при обсуждении вероятность понимания, при контроле со стороны проектировщика, очень высока.
Важен результат, но результат без скорости — ничто. Поэтому лучшее проектирование — это четкие списки задач и диаграммы.