Написание ТЗ. Нужно учить матчасть

Столкнулся с проектом средней тяжести реализации. Разработку запланировано вести в несколько самостоятельных стабильных промежуточных этапов.
Для того чтобы не держать кучу информации в голове (тем более, что это невозможно для обычного человека), а также, чтобы согласовать все с заказчиком и зафиксировать в письменном виде, мы решили составить полноценное Техническое Задание. Казалось бы, как можно вобще работать без ТЗ? Но на моей практике такое случается сплошь и рядом, хотя, конечно, в маленьких проектах.
Итак, первое ТЗ состоит из следующих разделов:

• Введение. В основном, здесь идет описание наших целей. Т.е. что это будет за сайт и какие у него будут цели существования, потенциальная аудитория.
• Общие требования к сайту. В этот раздел попадает список общих для всего сайта требований, таких как структура URI, критичная скорость загрузки, принципы шаблонизации и безопасности. Безопасность, впрочем, можно вынести и в отдельный раздел, но в моем случае практически ничего кроме шифрования паролей в md5 не указывалось (используемый PHP-фреймворк by default закрывает проверку входящих данных и т.п.).
• Пользовательские роли. Тут описывается практически вся реализация пользовательской части. В моем случае это описание основных групповых политик и ролей.
• Объекты. В данной части подробно описываются объекты сайта (новость, событие, пользователь,товар...) с указанием всех полей (в т.ч. обязательных) и состояний. При разработке повлияет на ОО-структуру и схему базы данных.
• Страницы и модели поведения. Этот раздел описывает основные страницы (ведь сайт, это по сути набор страниц или фактических состояний). Для примера, зафиксировано, что на странице новостей будет выводится список из 10 последних по дате новостей. Список будет состоять из даты новости, ее заголовка и текста аннотации и т.д. и т.п. вплоть до модели поведения системы при клике на заголовке новости. В этом же разделе можно описать систему администрирования.

Чего здесь не хватает? После нескольких редакций документ разросся и ему не хватает подробного содержания и краткого руководства "Как пользоваться этим документом". Еще здесь не хватает следующих вещей:

• Требований к дизайну и юзабилити (в частности, как будет выглядеть и логически работать календарь для выбора даты).
• Более научного подхода, к примеру UML диаграмм не только классов, но и Cases, т.е. тех самых моделей поведения, записанных не на словах, а в диаграммах.

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

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

Похоже, я буду докладчиком на PHPConf 2007

По предложению Александра Смирнова, создателя и идейного вдохновителя http://phpclub.ru я написал тезисы к докладу о независимой PHP-разработке (фрилансе), чтобы выступить в мае 2007 года на http://phpconf.ru.
В докладе планируется обобщить личный опыт и провести обзорное исследование феномена независимой РНР-разработки (фриланса) в России. Главный ориентир - не совмещение фриланса с основной работой full time, а полностью независимая разработка.Основные вехи доклада:

• Попытка классификации: полная занятость full time и удаленно, частичный freelance, полностью независимая разработка.
• Организационный вопрос: ИП, ООО, "неофициальная" занятость, физическое лицо по договору. Налоги.
• Наработка опыта и клиентской базы.
• Взаимоотношение с заказчиком (гарантии оплаты, варианты оплаты, коммуникации, технические задания).
• Фриланс vs Full Time: за и против.

Удастся ли в итоге, и что из этого получится будет видно только в мае. Ждите продолжения :)

Первая встреча с одним из заказчиков

Вчера встречался с потенциальным заказчиком. На меня его вывел один мой коллега, знакомый по phpclub, который снабдил его положительными рекомендациями (спасибо!).
Изначально я планировал встречу таким образом: мы встречаемся в центре Москвы (по договоренности это была кофейня n-joy на Кузнецких Воротах), знакомимся друг с другом и я рассказываю ему немного о своих профессиональных навыках, портфолио и прочих вещах по которым он сможет хоть как-то определить - подхожу я для его проекта или нет. В то же время, хотелось посмотреть и на него, чтобы понять - адекватен человек или проект сразу рискует превратиться в работу для камикадзе. Такая беседа очень хорошо помогает определиться, хотя бы предварительно. Методика заказчика по определению моей адекватности состояла из следующих направлений вопросов:

• Каким я вижу решение организационных вопросов (взаимные гарантии, взаимодействие в процессе разработки, разделение работы на этапы и оплату). По моему мнению, опытному заказчику мои ответы могли не только прояснить как мы можем сотрудничать конкретно с ним, но и в целом дать представление - есть у меня опыт решения таких вопросов или нет. Ведь если я ни бум-бум здесь, то встает вопрос - а были ли у меня раньше фрилансовые заказы или я выдаю себя не за того, кем являюсь.
• Чем данный проект будет для меня интересен? Тоже грамотный вопрос. Если проект не интересен с точки зрения реализации (а не денег) то для заказчика есть как минимум два риска - что я буду работать медленно без проявления фантазии и что проект мне надоест через месяц и я буду пытаться всеми силами выйти из него. Понятно, что оба риска вполне серьезны.
• В каких проектах я участвовал и что это за проекты? В моем конкретном случае у заказчика была рекомендация, а значит он не пытался устраивать мне тестирование на знание языка, но вопросы наподобие этого всегда позволяют оценить опыт разработчика в тех или иных сферах.

Я же специальных вопросов не задавал, но для меня были интересны следующие моменты:

• Сколько денег заказчик готов реально заплатить за проект. Нужно, чтобы он назвал конкретную сумму.
• Готов ли он платить дополнительно, если вдруг решит расширить проект или будет пытаться "вписать" новые задачи в старое ТЗ. Здесь в любом случае стоит предусматривать такой оборот дел, но лучше прояснить для себя все в самом начале.
• На какие сроки он рассчитывает и готов ли морально к их нарушению. Проект может разрастись, или могут вылезти неожиданные трудности - это все случается, причем не всегда по вине разработчика - некоторые вещи действительно сложно предугадать. Поэтому нужно понять - будет ли заказчик неадекватен или при должном обосновании с вашей стороны сможет как-то попытаться справиться с ситуацией. В любом случае, здесь разработчик должен всегда стараться предугадать тонкие места и как можно заранее предупреждать заказчика о возможных трудностях. О ленивости разработчика я здесь не говорю - мы рассматриваем ситуацию, когда программист действительно нацелен на успех проекта.
• Когда я получу первые деньги и что я должен для этого сделать?

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

Теперь, я должен буду выяснить о всех нужных функциях поподробнее, сформировать ТЗ и нарисовать статическую (HTML или в Visio) модель сайта. Тогда мы утвердим точный срок реализации этапа и деньги за его прохождение. Информация выясняется на дополнительных встречах путем интервьюирования заказчика.

Чем это хорошо? Во-первых, заказчик сможет за этот этап (2-4 недели) понять - действительно ли я могу реализовать то, что он хочет получить. Одно дело интуиция на собеседовании, а совсем другое - на практике. Если я не справлюсь с первым этапом, то он потеряет не полгода, а две недели, что тоже неприятно, но поправимо. С другой стороны, я, как разработчик смогу выявить платежеспособность и адекватность заказчика на практике и в крайнем случае потеряю также не полгода, а две недели.

Начало нового блога

О чем я собираюсь писать в этот блог?
О своих проектах, над которыми я работаю как фрилансер - настоящий независимый разработчик без работодателя, но с заказчиками.