Блог — Управление проектом по изменению сайта
25 мая 2009 в 22.38
Автор: Степан Овчинников
Сайты, работающие на бизнес, часто меняются. Не просто дополняются разделами и фишками, а именно изменяются в логике, интерфейсе, правах, протоколах взаимодействия с другими системами.
Часто такое изменение происходит с условием соблюдения множества условий: сохранения и переноса контента, обеспечения плавной замены старого на новый, обеспечения возможности поработать со «старым сайтом».
Также, как правило, между серьезными изменениями проходит достаточно времени, чтобы ПМ и программист прочно забыли половину деталей, в которых, как известно, дьявол.
Возникает множество вопросов при управлении таким проектом. Один из основных — описание требований, ТЗ.
Опишу ситуацию и путь решения на примере одного проектов.
Сайт представляет собой интернет-магазин со множеством точек и регионов продаж, синхронизируемый с учетной системой склада и бухгалтерии, разными ценами для дилеров, квотами поставщиков и прочими нетривиальностями.
Изменение касается самого главного: бизнес-логики.
Одни сущности убираются, другие изменяются, третьи начинают вести себя иначе, четвертые разбиваются на более мелкие, пятым заводится архив и отчетность по периодам.
На исходный сайт есть ТЗ. Но если он постоянно эксплуатируется, то ТЗ в лучшем случае соответствует реальности процентов на 80. В худшем — читать его будет вредно.
В нашем случае ТЗ приличное, но после основной разработки к нему было составлено 5 дополнительных ТЗ на доработки и цельно анализировать все по документам невозможно.
Требования сформулированы достаточно четко, но «в терминах заказчика», то есть никому из исполнителей работ такой документ давать нельзя, нужно все четко и всесторонне продумать.
Что я предлагаю делать в такой ситуации? Ничего оригинального, но мне такая процедура показалась единственно верной и достаточно эффективной. Может, у читателей будут другие соображения.
Этап 1. Вспомнить все.
Опираясь на исходную документацию, свою память и опросив всех причастных к проекту с обеих сторон, описать сжато все что и как сейчас делается в проекте, в том числе затронув бизнес-процессы в организации заказчика, особенно те, которые будем менять. Писать на языке, более близком к языку заказчика, нежели технарей — ему это надо будет проверить.
Этап 2. Написать как надо.
Надо переписать ТЗ заказчика (если его нет, написать, поговорив с каждым заинтересованным) на техническом языке, приложив максимум усилий для того, чтобы не пропустить последствия изменений. Например, если признаки сущностей перемещаются в другие сущности, описать изменения во всех связанных представлениях, отчетах и управлении.
На этом этапе всплывет масса вопросов, которые нужно урегулировать.
Этап 3. Продумать и зафиксировать план внедрения.
Будут ли системы жить параллельно? Будет ли тестовый период? Нужно и можно ли (именно в таком порядке) совместить их в одной избыточной БД? Должна ли остаться доступной «старая версия»?
Когда и как новая система будет запущена в реальную эксплуатацию? Если вы должны начать одновременно с внедрением, например, новой системы складского учета, это добавит сложностей.
Этап 4. Написать собственно ТЗ на изменения.
Этот документ существенно отличается от ТЗ на новый продукт по ряду причин:
— даже если старый код писал тот же человек, ряд решений могут ему показаться устаревшими и «некрасивыми» в свете новых требований. надо обязательно определиться с тем, что есть смысл переделать, а что проще и правильнее сделать костылями по соображениям времени и денег.
— когда код, верстка, клиентские скрипты и сценарии меняются, есть риск оставления скрытых ошибок и несоответствий логики старой и новой. Поэтому очень желательно чтобы в ТЗ были описаны очень подробно все изменения, которые должны сделать все исполнители. Разумеется, это требует, чтобы менеджеру проекта хватало квалификации.
— изменения в структуре данных и обмена между информационными системами надо описать особо и подробно. Думаю, что в большинстве студий физическую структуру данных определяет программист по общим требованиям проектировщика, так вот при изменениях с учетом требований этапа 3 изменения надо продумывать вместе и очень тщательно
Этап 4А. Todo.
Если в проекте занято более 1 человека, разметить конкретно кому что делать. Это можно сделать с помощью цветных маркеров пунктов или может потребоваться создание нескольких todo-листов для каждого.
Удобно эти изменения группировать по типам: в логике, в дизайне, в верстке, в панели управления, в структуре импорта-экспорта-резервирования и т.п.
Этап 5. Подписать ТЗ, начать и закончить все что описано.
Тут каждый менеджер сам знает как ему организовать процесс. Ключевое уже сделано.
В целом работа над такой задачей создает ощущение: все как с новым сайтом, только вдвое сложнее. Доверстка, допроектирование, допрограммирование, конвертация данных заставляет помнить и урегулировать массу нюансов и тонкостей и в целом предъявляет более высокие требования к менеджеру проекта.