Интересный проект, адекватные сроки, современная методология, команда с чётко прописанными обязанностями и разными скиллами. Но что происходит, если это только слова, а на деле вас ждёт суровая реальность?
Дано:
- Что: проект по разработке веб-приложения.
- Срок: 5 месяцев.
- Заказчик: директор креативной европейской компании, человек, для которого дизайн — это главное.
- Методология: Scrum.
- Команда: территориально распределённая команда, два представителя страны N из ЕС, три человека из РФ.
- Изначальные роли: Scrum Master, Product Owner, два программиста и один дизайнер.
Казалось бы, что может пойти не так, многие команды так работают, пусть даже и Scrum на расстоянии не самая практикуемая вещь. Сроки реальные, команда выглядит скилловой, и ничего не предвещает беды.
А теперь представьте, что в этой команде работают только два человека. Не то, чтобы все сбежали, все продолжают присутствовать, но Scrum Master плавает в терминологии, да и о Scrum узнал пару недель назад на семинаре, а Product Owner очень стеснительный человек, а программисты — фрилансеры, и у них есть более радостные занятия в жизни. Звучит пугающе и выглядит как огромный красный крест на успехе проекта, но давайте посмотрим, что происходит дальше.
Начнём с небольшого экскурса в обязанности в обязанности каждого члена команды.
Scrum Master – человек- ас методологии, готов выстраивать процесс, поддерживает здоровые коммуникации в команде, делает открытыми обсуждения пожеланий, предложений и проблем, следит за графиками, побуждает всех к постоянной коммуникации и конечно же мотивирует людей, ведь в гибких методологиях именно процесс очень важен, когда ты с желанием движешься вперёд, улучшая свою работу.
Product Owner – по сути единственный, кто понимает, что и как нужно делать. Он единственный, кто знает, что именно хочет заказчик, и в то же время единственный, кто может иногда притормозить и сказать «нет». Именно он отвечает за состав бэклога и приёмку спринта. Этот человек открыт к обсуждению, а также донесению видения заказчика до программистов, а также донесения технических особенностей и ограничений для заказчика.
Дизайнер — в данном проекте предполагалось, что именно этот человек будет подготавливать прототипы приложения, отвечать за «красоту» продукта, а также полирование результатов разработки.
Программисты – уж простите, но в них не было ничего особенного. Они должны были понимать, как кодить и что кодить.
А что же было на самом деле? Кто же были эти два человека? Дизайнер и программист. Наверное, они забили на методологию и просто делали? Нет. Наверное, они провалили проект? Нет. Наверное, было тяжко? О да. Давайте рассмотрим, какие новые обязанности появились у них. Дизайнер стал единственным человеком, кто понимал, что нужно делать, когда нужно делать, а что делать не нужно или невозможно. Дизайнер писал тест для так называемого «Product Owner», чтобы тот донёс его до заказчика, так как они находились в одном городе в Европе. В этом тексте расписывались технические особенности системы и обоснование невозможности реализации «хотелок» клиента. А ещё дизайнер вдвоём с программистом проводили ежедневные пятиминутки, сами планировали себе спринты, оценивали задачи, отчитывались для формальности «Product Owner», сидели ночами, пытаясь изобрести новые технологии, которые бы удовлетворяли клиента и Product Owner, потому что он требовал всё то, что хочет заказчик, без вариантов да побыстрее. Программист в это время днями и ночами кодил, верстал, переделывал, переводил, снова не спал и плюс пытался бороться с техническими ограничениями хостинга, потому что клиент не был готов платить за новый. Какой же результат? Проект сдан, да корявенький, но работающий. Мануалы для пользователей написаны. Сайт с английского переведён на язык европейской страны N. Как сейчас говорят, проект был «challenged».
Какие же уроки можно вынести из всего это:
- Набирайте только компетентных людей в проект.
- Не выбирайте методологию, если вы не понимаете для чего, кому и какую пользу она принесёт.
- Мотивируйте команду работать как единое целое.
- Не сдавайтесь, даже если кажется что всё плохо.
- Остерегайтесь, когда заказчика описывают как «очень творческий и открытый для всего нового» человек.
В общем, удачи вам в ваших проектах!
Искренне ваш,
Дизайнер.
