Веб-проекты, как и женщины, бывают разные — умные, красивые, соблазнительные и… мгновенно сводящие с ума. Довольно часто веб-проекты — это сайтики с несложной логикой и понятными технологиями. Завалить такой проект — нужно очень постараться, да и потом совесть будет мучить всю жизнь за лень и глупость.
Но иногда к вам приходит проект вкусный и интересный, красивый и сложный, с выглядывающимиз под… дедлайном в следующем квартале. За вечер можно вникнуть только в треть его предметной области — как со стороны функционала, так и технологий. Адреналин (и тестостерон) конечно зашкаливает — решить такую непростую задачу, красиво, очень хочется, но проснувшись утром вы видите, что поседели — безуспешно пытаясь найти алгоритм в полудреме.
Самое страшное начинается по мере приближения подобных систем к дню запуска. Допущенные при проектировании мельчайшие ошибки и недодумки начинают с визгом пропускать воду в кают-кампанию на глубине 5000 метров.
Готовых рецептов как победить и выпустить такой проект в срок — в статье не будет. Но я постараюсь разобрать часто возникающие риски, связанные с потоком требований и дать рекомендации — как увеличить шансы на победу.
Я опишу цепочку немного нестандартно, снизу вверх — от технической реализации к требованиям, а не наоборот, как часто встречается.
Разработчик несет большой груз ответственности за свой код — возрастающий с каждой новой строчкой. Поэтому пишет программу и хочет решить задачи проекта правильно и точно, без вероятностей и логической слизи. Ведь создаваемый код — это выточенная металлическая конструкция на шарнирах с электродвигателями, кристаллизация математического алгоритма. Ересь про гибкий код, настраиваемые шаблоны проектирования, рефакторинг и 10 500 юнит-тестов — придумали коррумпированные менеджеры :-)
Программисту одинаково сложно и важно понять и реализовать алгоритм сортировки строк в файле в RB-tree, отследить возможные состояния сокетов асинхронного сетевого tcp сервера или обработать данные формы авторизации. Нужно все равно вникнуть во все детали, тщательно и глубоко. Но чтобы разработчик сделал свою работу хорошо — нужен кто-то, кто сможет дать точные ответы на его конкретные формальные вопросы: «сколько глаз у некроморфа, сколько стрел воткнуть в вампира и т.п.» — сразу или в оговоренный срок. Если заставить разработчика самому разбираться в предметной области и ходить по кладбищам по ночам с мачете в поисках ответов — кто и когда будет писать работающий код?
Т.к. разработчик отвечает за реализованный программный код и для него каждая ошибка отдается болью в сердце и разрастанием кармы — любые неясности, муть, вода и путаница в требованиях во время программирования — это те самые глупые и ненужные риски, которые нужно постараться максимально снизить. Самое главное — их можно снизить!
Известно же, что вносить серьезные изменения в программный код потом (да, я знаю про паттерны программирования, но они не всесильны), когда он отлажен, протестирован, вылизан — не только неопределенно сдвигает срок реализации веб-проекта, но и пропитывает систему трудноуловимыми ошибками.
В конце концов, попросите прораба, после штукатурки и наклейки обоев, заменить в стенах электропроводку на более толстую и медную… за его счет — ну прораб же должен был, блин, предусмотреть этот сценарий изменения требований? :-) Глупо же — а в разработке это частый кейс, к большому сожалению.
Двигаемся выше по цепочке.
Со стороны руководства компании — менеджер веб-проекта отвечает за успех проекта, в т.ч. путем выявления и снижения проектных рисков — т.е. он должен сам давать ответы или найти того, кто ответит разработчику точно на возникающие вопросы по предметной области.
Например, можно включить в проектную группу аналитика, эксперта или толкового представителя заказчика — который будет не спать ночами, пока в деталях не раскопает все тонкости и логику проектируемой системы. Или менеджер должен сам погрузиться в проект, предметную область и сделать это работу сам.
Если менеджер начнет «переводить стрелки» в бесконечной рекурсии внутри компании, игнорировать детали проекта с высоты орбиты Земли, пускать «туманчика,» вздрагивать от вопросов или отвечать на вопросы лишь бы отмазаться — эта каша просочится в производство и засохнет в виде неспособного к жизни кода, покрытого бесполезными тестами и этот кошмар вскроется при ближайшей демонстрации функционала клиенту. Остается — все переписать, сорвав срок и бюджет… или взорвать.
Даже небольшие пропущенные порции «воды» в требованиях, особенно касающихся фундаментальных вещей — очень сильно подрывают устойчивость создаваемой системы. Да, если у вас в команде очень опытные бойцы — они скорее всего локализуют «воду», обложат ее изоляцией и будут кричать о неточностях и мути предметной области, пока не докричатся. Но обычно проблема вскрывается за день перед запуском.
С требованиями менеджеру (эксперту, аналитику) придется… эхх… поработать, закатив рукава. Могу порекомендовать следующие полезные инструменты:
— глоссарий
— usecases или сценарии использования
— отношения сущностей глоссария между собой (1 ко многим, N к M и т.п.)
— activity diagram или обычная школьная блок-схема
В ходе уточнения требований выясняются как сущности системы, так и их свойства и взаимодействие между сущностями.
Вот пример: «покупатель может принадлежать группе клиентов, получающих скидку».
Вопросы, ответы на которые должны быть понятны перед началом разработки:
— Покупатель может входить в несколько групп?
— Как в этом случае рассчитывается скидка? Нужна формула.
— На какой срок покупатель включается в группу?
— При удалении покупателя из группы его уведомить? По емейлу или смс?
и т.д, и т.п.
На все вопросы придется дать точный и формальный ответ, и не сваливать это на разработчика: «программист как-то решил, он же умный, я не знаю как».
1) Проверьте цепочку формирования требований от менеджера, аналитика — к программисту. Люди понимают, что они делают, как это будет работать в деталях?
2) Насколько клиент, как эксперт в предметной области, участвует в процессе проектирования и уточнения требований. Или он ждет и грезит? :-)
3) Задайте менеджеру веб-проекта пару вопросов, уточняющих детали предметной области и если в ответ польется вода… примите меры по экстренной мотивации :-)
4) Поговорите с разработчиками — кто и как отвечает им на вопросы по предметной области, как четко и непротиворечиво? Им все понятно?
5) Как часто меняются требования и «едет» предметная область по причине «невникания» менеджера проекта в детали и начала «вникания» перед дедлайном? Как часто приходится из-за не проработанности предметной области до кровоточения из глаз менять код за день до запуска и почему (и 2 недели править баги ночью)?
Соблюдение перечисленных мер оздоровления потока требований сверху вниз — резко увеличивают шансы веб-проекта на успех!
Всем удачи.
Но иногда к вам приходит проект вкусный и интересный, красивый и сложный, с выглядывающим
Самое страшное начинается по мере приближения подобных систем к дню запуска. Допущенные при проектировании мельчайшие ошибки и недодумки начинают с визгом пропускать воду в кают-кампанию на глубине 5000 метров.
Готовых рецептов как победить и выпустить такой проект в срок — в статье не будет. Но я постараюсь разобрать часто возникающие риски, связанные с потоком требований и дать рекомендации — как увеличить шансы на победу.
Я опишу цепочку немного нестандартно, снизу вверх — от технической реализации к требованиям, а не наоборот, как часто встречается.
Роль — Разработчик
Разработчик несет большой груз ответственности за свой код — возрастающий с каждой новой строчкой. Поэтому пишет программу и хочет решить задачи проекта правильно и точно, без вероятностей и логической слизи. Ведь создаваемый код — это выточенная металлическая конструкция на шарнирах с электродвигателями, кристаллизация математического алгоритма. Ересь про гибкий код, настраиваемые шаблоны проектирования, рефакторинг и 10 500 юнит-тестов — придумали коррумпированные менеджеры :-)
Программисту одинаково сложно и важно понять и реализовать алгоритм сортировки строк в файле в RB-tree, отследить возможные состояния сокетов асинхронного сетевого tcp сервера или обработать данные формы авторизации. Нужно все равно вникнуть во все детали, тщательно и глубоко. Но чтобы разработчик сделал свою работу хорошо — нужен кто-то, кто сможет дать точные ответы на его конкретные формальные вопросы: «сколько глаз у некроморфа, сколько стрел воткнуть в вампира и т.п.» — сразу или в оговоренный срок. Если заставить разработчика самому разбираться в предметной области и ходить по кладбищам по ночам с мачете в поисках ответов — кто и когда будет писать работающий код?
Т.к. разработчик отвечает за реализованный программный код и для него каждая ошибка отдается болью в сердце и разрастанием кармы — любые неясности, муть, вода и путаница в требованиях во время программирования — это те самые глупые и ненужные риски, которые нужно постараться максимально снизить. Самое главное — их можно снизить!
Известно же, что вносить серьезные изменения в программный код потом (да, я знаю про паттерны программирования, но они не всесильны), когда он отлажен, протестирован, вылизан — не только неопределенно сдвигает срок реализации веб-проекта, но и пропитывает систему трудноуловимыми ошибками.
В конце концов, попросите прораба, после штукатурки и наклейки обоев, заменить в стенах электропроводку на более толстую и медную… за его счет — ну прораб же должен был, блин, предусмотреть этот сценарий изменения требований? :-) Глупо же — а в разработке это частый кейс, к большому сожалению.
Двигаемся выше по цепочке.
Роль — Менеджер
Со стороны руководства компании — менеджер веб-проекта отвечает за успех проекта, в т.ч. путем выявления и снижения проектных рисков — т.е. он должен сам давать ответы или найти того, кто ответит разработчику точно на возникающие вопросы по предметной области.
Например, можно включить в проектную группу аналитика, эксперта или толкового представителя заказчика — который будет не спать ночами, пока в деталях не раскопает все тонкости и логику проектируемой системы. Или менеджер должен сам погрузиться в проект, предметную область и сделать это работу сам.
Если менеджер начнет «переводить стрелки» в бесконечной рекурсии внутри компании, игнорировать детали проекта с высоты орбиты Земли, пускать «туманчика,» вздрагивать от вопросов или отвечать на вопросы лишь бы отмазаться — эта каша просочится в производство и засохнет в виде неспособного к жизни кода, покрытого бесполезными тестами и этот кошмар вскроется при ближайшей демонстрации функционала клиенту. Остается — все переписать, сорвав срок и бюджет… или взорвать.
Даже небольшие пропущенные порции «воды» в требованиях, особенно касающихся фундаментальных вещей — очень сильно подрывают устойчивость создаваемой системы. Да, если у вас в команде очень опытные бойцы — они скорее всего локализуют «воду», обложат ее изоляцией и будут кричать о неточностях и мути предметной области, пока не докричатся. Но обычно проблема вскрывается за день перед запуском.
Инструменты
С требованиями менеджеру (эксперту, аналитику) придется… эхх… поработать, закатив рукава. Могу порекомендовать следующие полезные инструменты:
— глоссарий
— usecases или сценарии использования
— отношения сущностей глоссария между собой (1 ко многим, N к M и т.п.)
— activity diagram или обычная школьная блок-схема
В ходе уточнения требований выясняются как сущности системы, так и их свойства и взаимодействие между сущностями.
Вот пример: «покупатель может принадлежать группе клиентов, получающих скидку».
Вопросы, ответы на которые должны быть понятны перед началом разработки:
— Покупатель может входить в несколько групп?
— Как в этом случае рассчитывается скидка? Нужна формула.
— На какой срок покупатель включается в группу?
— При удалении покупателя из группы его уведомить? По емейлу или смс?
и т.д, и т.п.
На все вопросы придется дать точный и формальный ответ, и не сваливать это на разработчика: «программист как-то решил, он же умный, я не знаю как».
Пути снижения рисков
1) Проверьте цепочку формирования требований от менеджера, аналитика — к программисту. Люди понимают, что они делают, как это будет работать в деталях?
2) Насколько клиент, как эксперт в предметной области, участвует в процессе проектирования и уточнения требований. Или он ждет и грезит? :-)
3) Задайте менеджеру веб-проекта пару вопросов, уточняющих детали предметной области и если в ответ польется вода… примите меры по экстренной мотивации :-)
4) Поговорите с разработчиками — кто и как отвечает им на вопросы по предметной области, как четко и непротиворечиво? Им все понятно?
5) Как часто меняются требования и «едет» предметная область по причине «невникания» менеджера проекта в детали и начала «вникания» перед дедлайном? Как часто приходится из-за не проработанности предметной области до кровоточения из глаз менять код за день до запуска и почему (и 2 недели править баги ночью)?
Соблюдение перечисленных мер оздоровления потока требований сверху вниз — резко увеличивают шансы веб-проекта на успех!
Всем удачи.
