В России заказной веб-разработкой занимаются более 5000 компаний (по данным аналитического агентства Слоган ), однако, на мой взгляд, наш рынок пока находится в зачаточном состоянии.
Многие цифровые компании, веб-студии и интеграторы в реальности не готовы к качественной разработке и поддержке по-настоящему крупных проектов.
Посетите нас по адресу АГИМА К нам часто обращаются компании, недовольные качеством работ своего нынешнего подрядчика, которого они выбрали посредством тендера.
За долгие годы работы с крупнейшими российскими компаниями мы накопили огромный опыт в организации процессов проектирования и разработки крупных интернет-проектов, и я хочу им поделиться.
В этой статье я расскажу, как правильно организовать инфраструктуру, выстроить коммуникации между командами и не забывать о важных составляющих агентского сервиса при работе с «гигантами».
Что я считаю крупным проектом? Если проект производит в общей сложности более 2500 человеко-часов в месяц всей командой проекта, не считая работы менеджера.
По объему работ это, как правило, 2-3 крупные задачи по 800-1000 человеко-часов параллельно и 5-6 небольших ежедневных задач в рамках определенных подписок на техподдержку.
Это могут быть сайты крупных страховых компаний, банков, крупных интернет-магазинов, корпоративных порталов, HR-порталов и СМИ.
Чего ожидать в статье: Руководство по требованиям к организации команды и процессам при проектировании, разработке и поддержке крупных проектов.
Он основан на 10-летнем опыте работы на рынке веб-разработки на заказ.
За это время мне удалось запустить более 100 проектов.
Последние два года я руководил разработкой и сопровождением проектов компании «АльфаСтрахование».
Для кого предназначена эта статья: Статья будет интересна менеджерам проектов и всем, кто так или иначе участвует в организации процессов разработки веб-приложений и взаимодействии с клиентом.
Отказ от ответственности: Данная статья не панацея, а лишь сугубо личное мнение автора (Евгения Лобанова, исполнительного директора АГИМА).
Поздравляем, у вас есть крупный проект! Неважно, как вы это получили.
Часто большие проекты вырастают из простых задач: либо вы удовлетворяете клиента на маленькой задаче и он решает вам всю поддержку и развитие, либо вы растёте вместе с клиентом — это лучший вариант. А возможно, вы просто свалили и, сами того не ожидая, выиграли тендер на поддержку и развитие крупного проекта.
Например, один из самых первых наших «гигантских» проектов вырос из небольших технических доработок по требованиям SEO-специалистов.
В какой-то момент клиент сказал: «Мы хотим запустить новую версию сайта, почти все готово, но наш нынешний подрядчик не может ее доделать.
Нам понравилось, как быстро вы вносите улучшения.
Давай закончим и запустимЭ» Мы столкнулись с тем, что мы получили контракт, но у нас не было инфраструктуры и налаженных процессов для проектов такого уровня.
Что делать? КОМАНДА Начали мы с самого главного — отдельно для проекта сформировали новую команду, ведь если у вас нет рук, то большой объем задач вы не сможете «переварить».
Процесс отбора команды стал одним из самых сложных и длительных этапов.
Мы отфильтровали массу резюме и провели массу собеседований.
Поиск мы начали с руководителя проекта и тимлида, так как это ключевые роли в любом проекте, и они уже участвовали в дальнейшем подборе команды, это позволило нам более эффективно подойти к поиску других участников.
Первая линия 
Большой проект всегда подразумевает много коммуникаций (в нашем случае на стороне клиента было более 3-х менеджеров, отвечающих за определенные типы задач), поэтому нам пришлось создать единую точку входа.
На тот момент проектом руководил один менеджер, и он не мог справиться с потоком запросов на оценки, задачи, вопросы и баги, которые на него обрушивались.
Когда мы попытались затащить всех ответственных людей в наш диспетчер задач, то сразу столкнулись с огромным количеством дублей и отвратительной проработкой задач (некоторые из них могли противоречить друг другу, так как были из разных бизнес-подразделений, но на общих страницах).
: дом, новости и так далее.
).
Тогда мы решили попробовать достаточно простую вещь — ввели роль администратора проекта.
Это анонимизированный адрес электронной почты «Техподдержки», на который поступают все запросы от клиентских менеджеров в рамках одного проекта; его могут обработать несколько преданных своему делу сотрудников.
Объем коммуникаций настолько велик, что полностью поглощает рабочие ресурсы как минимум одного члена команды.
Чтобы помочь менеджеру проекта управлять потоком запросов, мы наняли администратора проекта.
Это первая линия, которая следит за эффективностью связи, поэтому время ответа на любой запрос должно составлять не более 15 минут. Первая линия управляет ожиданиями клиента, поэтому должна оперативно «пинговать» руководителя проекта, тимлидов или клиента, если от него долгое время нет обратной связи.
В обязанности первой линии также входит подготовка ежемесячных отчетов по технической поддержке.
Каждую задачу необходимо внести в диспетчер задач.
Нет задачи – нет задачи.
Все задачи обновляются и маршрутизируются администратором проекта.
Это освободило нашего менеджера проекта для других, более тактически важных обязанностей.
Руководитель проекта 
Мы давно решили, что всю ответственность за проект несет руководитель проекта, и только он.
Это человек, который планирует, составляет тайминги для каждой задачи, определяет приоритеты и учитывает все риски.
Именно он принимает ключевые решения (использование той или иной реализации и методологии, решение о запуске на продуктивной среде, привлечение экспертизы сотрудников), а также участвует в решении возникающих проблем.
У нас прописаны прозрачные KPI, в том числе ПМ должен следить за эффективностью первой линии и выполнением SLA, а также отвечать за рентабельность проекта и четкую постановку задач.
Если исходная задача изменится, он должен обосновать и защитить изменения стоимости и расписания для каждой дополнительной подзадачи.
В случае возникновения споров слова должны быть подкреплены фактами, поэтому все обсуждения необходимо фиксировать в документах или хотя бы письменно, например по почте.
Вся работа тщательно контролируется высшим руководством: аккаунт-директором и техническим директором, которые еженедельно просматривают все задачи из плана работы на ближайший месяц.
Руководитель группы 
Это последнее звено проекта, принимающее решение о запуске задачи в производство.
В нашей компании много проектов со сложными интеграционными задачами, поэтому основная нагрузка ложится на плечи тимлидов — для масштабирования под большие проекты мы подключаем 2 тимлидов одновременно.
Мы начали это делать не сразу, а только с осознанием критичности отпуска или болезни, когда руководитель группы был один.
Но, к сожалению, найти готового тимлида очень сложно, поэтому правильнее обучать его у хороших программистов.
Не каждый программист может быть тимлидом — руководитель команды разработчиков должен обладать управленческими навыками.
Владелец продукта 
В какой-то момент мы поняли, что нам нужен человек, который управлял бы потоком мыслей клиента, направлял стратегию развития проекта в правильное русло и давал внутренние консультации команде по продукту.
Владелец продукта должен знать больше о специфике бизнеса и продукта, чем клиент, и уметь предвидеть все нюансы.
Мы взяли такого человека с рынка клиента, чтобы он и вся команда могли подобрать оптимальное решение бизнес-задач и вместе с руководителем проекта и клиентом управлять нагрузкой команды.
Bench: подключенные специалисты 
Помимо основных специалистов (дизайнеров, верстальщиков, программистов, тестировщиков) крупные проекты часто требуют дополнительных ресурсов.
В наших крупных проектах нам чаще всего нужны:
- Архитектор
Зачастую своевременное привлечение архитектора может избавить вас от дальнейшего рефакторинга, продать который клиенту будет практически невозможно.
Любая новая задача на этапе проектирования также проходит через архитектора и владельца продукта.
- Аналитик
Данные, собранные на этапе аналитики, являются фундаментом дальнейшего интерфейса не только при его проектировании, но и при проектировании.
Мы применяем веб-аналитику для тех задач, где есть спорные технические и интерфейсные различия.
Они могут возникнуть не только в общении с клиентом, но и внутри самой команды.
В таких случаях мы прибегаем к сплит-тестам и по результатам применяем лучшие решения в конечном продукте.
- Дизайнер
Помимо прототипов, мы всегда разрабатываем пояснительную документацию (технические условия) к прототипам.
Это снижает дополнительные затраты на этапе проектирования и компоновки, а также облегчает контроль проекта со стороны дизайнера и руководителя проекта.
Для рефакторинга функциональности со сложными интеграциями мы привлекаем дизайнера в тандеме с руководителем группы.
Это позволяет оптимизировать текущую схему интеграции, выявить все недостатки и дать рекомендации по их устранению.
Таким образом, разрабатывается документ под названием «Анализ услуги», где все подробно описано.
- UX
Если есть явные проблемы, переделываем за свой счет. Инструментарий наших UX-специалистов:
- юзабилити-тестирование;
- опрос;
- прямая и обратная сортировка карт;
- дневниковое исследование;
- анализ обратной связи;
- семантический и сентиментальный анализ текстов.
Нагрузка на крупных проектах может как увеличиваться, так и резко уменьшаться.
Всегда есть возможность плавающего объема задач, а также мы предусмотрели возможность быстрого масштабирования.
Для этого привлекаются удаленные команды, поскольку нет смысла раздувать внутренний штат, если через месяц его нужно существенно сократить.
Такие команды всегда смогут подстраховаться на случай внезапной необходимости увеличения количества ресурсов.
При этом мы документально оформили у клиента, что сроки внесения новой крупной задачи в производственный план могут составлять до пяти рабочих дней.
ПРОЦЕССЫ Методология При работе над крупными проектами крайне важно выбрать правильную методологию.
Мы пришли к выводу, что зачастую на крупных проектах невозможно ограничиться одной схемой работы и реализовать весь проект только с использованием каскадных или гибких методологий.
Мы используем смешанные методологии, используя спринты и канбан-доски как часть итераций водопадного процесса.
И главное, что мы поняли: независимо от методологии, важно, чтобы в процессе решения задач участвовала вся команда.
Рабочие процессы В качестве второго глобального шага мы договорились с клиентом о четком рабочем процессе.
Например, релизы мы проводим по вторникам, оценки по средам, планирование задач в производственном плане на неделю, а в четверг у нас ретроспектива.
График строго контролируется администратором проекта на уровне трекера задач и менеджером проекта на уровне запросов от клиента.
Говоря о правильном планировании ресурсов, мы во всех расчетах в смете и планировании фиксировали, что рабочий день исполнителя составляет 6 часов, а не 8. Кроме того, необходимо заранее планировать время на случай аварий и ошибок, а зачастую и на поиск и анализ ошибки занимает 90% времени, а исправление только 10%.
Чтобы ускорить исправление ошибок, мы разделили ресурсы: техподдержкой и производством занимаются разные технические команды, точками пересечения являются только менеджмент и тимлиды.
Тестирование и контроль качества Крупные проекты всегда подразумевают сложную архитектуру, большую загруженность и большую финансовую ответственность.
Поэтому все критически важные функции должны быть покрыты сетью функциональных тестов.
Это позволяет предотвратить потенциальные проблемы и оптимизировать время на исправление ошибок.
Проблема подключенной архитектуры преследовала нас уже давно и добавляла негатива в наши отношения с клиентом.
Как можно быть уверенным в качестве производимой продукции? Во-первых, в процессе разработки проекта мы стали использовать стандартизированные контрольные списки .
Во-вторых, мы начали писать пользовательские кейсы еще на этапе проектирования приложения, это снизило многие риски и затраты на этапе разработки, например, многократную передачу задач между программистом и тестировщиком.
Если после повторного тестирования задача возвращается разработчику – это уже сигнал о проблеме, а если это происходит второй и более раз, нужно подключиться и выяснить, в чем причина.
Автоматизированное тестирование в рамках CI (gitflow) Сколько бы мы ни тестировали, ошибки были, есть и будут. Мы задали себе вопрос: как минимизировать время, затрачиваемое на анализ ошибок, и быстро реагировать на аварии? Мониторинг доступности и непрерывности функционирования позволил эффективно решить эту проблему.
Мы разработали специальный виджет событий, который агрегирует данные по каждому критическому списку url для бесперебойной работы (данные берутся из нашей собственной системы мониторинга zabbix и двух внешних независимых сервисов мониторинга) и данные функциональной доступности (с нашего билд-сервера TeamCity) .
При возникновении проблем с доступностью или функциональных ошибок срабатывает система оповещения: все ответственные лица получают электронное письмо, смс и звонок на мобильный телефон.
Таким образом, наше время реагирования на любой простой составляет не более 15 минут. 
Мы взяли за правило запускать функциональные тесты для списка критических URL-адресов:
- Ежедневный пробег в автоматическом режиме по расписанию (9:00 и 18:00).
- Проработка на платформе разработки специалистом перед отправкой (разработка ведется в фиче-ветках, каждая со своей выделенной платформой).
При фиксации выполняются перехватчики, которые запускают проверки кода и модульные тесты.
После успешного завершения тестов ветка разработки автоматически объединяется со стабильной веткой разработки и обновляется.
Далее начинается автоматизированное функциональное тестирование пользовательских сценариев.
Перед этим скрипт также подготавливает среду: принудительно очищает кеш, минимизирует необходимые файлы и запускает установщики, если изменения влияют на изменения в базе данных.
По результатам тестирования формируется отчет, доступный всем заинтересованным лицам (разработчикам, менеджерам, тестировщикам) и отправляется уведомление на электронную почту со статусом завершения тестирования.
- Запускайте на сцене (практически полный дубликат продуктивного сервера) и в бою, после выхода сборки.
Методические рекомендации Ошибки бывают не только технические, но и визуальные.
Подготовленные рекомендации для дизайнеров и верстальщиков позволяют свести их к минимуму (примеры 1 И 2 ), которые обеспечивают все состояния управления и обработку ошибок.
У нас также есть рекомендации для программистов ( пример ).
Это документация, описание классов и методов, механизмов интеграции и т.д. Всю эту полезную информацию мы агрегируем и храним в своей базе знаний (используем слияние ) — за обновление информации отвечают менеджеры проектов.
Важно продумать грамотную архитектуру, которая потребует минимум «костылей» на стадии доработки и разработки функционала.
При разработке кода мы придерживаемся стандартов ПСР-1 И ПСР-2 .
Это позволяет сократить время при переключении и передаче задач между разработчиками и тимлидами.
Те, кто работает в IDE, например PHPStorm, могут настроить автоматическая проверка соответствия стандартам .
Мы реализовали автоматическую проверку кода на стороне внутреннего сервера с помощью phpSniffer. Также при разработке архитектуры мы всегда учитываем требования информационной безопасности: контроль целостности кода, соответствие 152 ФЗ, отсутствие уязвимостей xss и sql-инъекций и соответствие ТОП-10 требованиям OWASP. На самом деле продавать руководства, документацию и автотесты очень сложно.
Часто студии не включают эту работу в смету, что приводит к страшному слову.
«рефакторинг», но, как правило, с другой командой подрядчиков.
Поэтому необходимо сразу серьезно подойти к проектированию и разработке проектов.
Заранее готовьтесь к поддержке крупных клиентов – это, в первую очередь, развивает наш рынок и позволяет выпускать по-настоящему качественные проекты.
P.S. В следующей статье этой серии мы подробно рассмотрим инструменты для менеджеров проектов, которые помогают структурировать и оптимизировать планирование и организацию процессов на проекте.
Теги: #Управление проектами #Управление продуктами #управление проектами #agima
-
Выбор Надежного Компьютерного Сервиса
19 Oct, 24 -
Бесплатные Ноты В Сети — Правда Или Вымысел?
19 Oct, 24 -
Каково На Самом Деле Работать В Коворкинге
19 Oct, 24 -
Что Нам Делать С Ie6?
19 Oct, 24
