190 проектов каждый день: как не потерять качество при разработке ПО
Всем привет! На связи Сергей Гордеев, руководитель проектного офиса ИТ-компании SimbirSoft. За 20+ лет разработки софта мы выросли из команды в четыре человека до компании с полутора тысячами специалистов в штате. В нашем портфолио уже более 1200 реализованных проектов. Мы создаем и кастомизируем информационные системы для решения бизнес-задач клиентов из разных отраслей, в том числе делаем высоконагруженные системы с использованием Machine Learning и Data Science. Компания стабильно развивается во многом потому, что мы быстро адаптируемся под меняющиеся рыночные условия, у нас сильный менеджмент и выстроенные процессы.
В основе нашего успеха лежит то, что мы стараемся всегда создавать качественный продукт для бизнеса — независимо от масштаба и известности клиента. Чтобы делать хорошо, вникаем в специфику бизнеса заказчика и ищем первопричину обращения к нам. Сейчас мы параллельно ведем почти две сотни проектов. Как нам удается достигать результатов при такой нагрузке — расскажу в статье.
Итак, что же нам помогает обеспечивать качественную работу над несколькими сотнями проектов, расскажу далее.
Работать с командой заказчика как со своей
Мы находимся с клиентом в одной лодке, у нас общая цель — качественный продукт, который решает имеющуюся бизнес-проблему. Поэтому мы не просто делаем что скажут, а проникаем в суть проблемы заказчика и находим то, что нужно для ее решения.
Если мы понимаем, что клиенту сейчас не нужна дорогостоящая информационная система, которую он хотел, и его задачу можно решить с помощью более дешевого решения, мы честно ему об этом скажем и предложим варианты.
Мы ориентируемся, прежде всего, на потребности бизнеса и направляем все силы на то, чтобы сделать максимально результативно и качественно: использовать новые технологии, не допускать ошибок. И даже «простой» продукт разрабатываем так, чтобы он нес максимальную ценность для клиента и конечных пользователей.
На стороне заказчика не всегда есть необходимые компетенции и опыт, но, если это в конечном итоге влияет на ход проекта и достижение результата, мы обязательно предложим нивелировать просадку за счет привлечения экспертизы с нашей стороны. Как правило, в таких случаях клиент нас поддерживает: он всегда заинтересован в сотрудничестве, если это помогает получить нужный результат и решить задачи. Таким образом, происходит максимально гибкая подстройка под клиента.
Оставаться с заказчиком на одной волне
За годы практики мы выработали несколько принципов работы с клиентом, которые помогают нам понимать, чего хочет заказчик, и действовать в соответствии с его требованиями. Вот основные из них:
Быть в контакте. Мы часто взаимодействуем с клиентом, обсуждаем видение и детали, чтобы в конечном итоге достигнуть нужного результата, и всегда остаемся на связи.
Фиксировать ответственность. На старте проекта составляем матрицу ответственности — фиксируем задачи и ожидания заказчика, распределяем роли и обязанности. Если в процессе что-то идет не так — проводим ретроспективу, даем всем участникам высказаться и вносим корректировки по результатам обратной связи.
Фиксировать точки контроля. Заранее согласовываем с заказчиком план созвонов, на которых демонстрируем промежуточные результаты по проекту.
Быть предсказуемыми. Все процессы на проекте прозрачны для клиента — он знает, что сейчас происходит и сколько времени будет длиться каждый этап. Это координирует руководитель проекта.
Разрабатывать новое, используя накопленный опыт
После реализации каждого проекта мы проводим ретроспективу, обсуждаем полученный опыт, удачные идеи, которые можно использовать для разработки других подобных ИТ-систем, а также вносим изменения в процессы, чтобы в будущем избежать совершённых ошибок. Таким образом у нас формируется актуальная база знаний, куда могут зайти сотрудники и посмотреть, какой проект реализовывали и что получили в итоге.
Также у нас есть база знаний по технологиям. У SimbirSoft, естественно, есть свои наработки — удачные технические решения, которые мы стараемся переиспользовать, если такая возможность есть. Это позволяет снизить трудозатраты на реализацию проекта, а значит, и сэкономить деньги клиента. Условно: специалист мог бы потратить неделю на продумывание архитектуры, а вместо этого использует наработки и делает всё за день.
Делать лучшее из возможного
Как я уже упоминал, мы всегда стараемся предложить заказчику разные варианты решения его бизнес-задачи исходя из тех или иных ограничений по бюджету, сроку и качеству.
Чтобы максимально попасть в ожидания заказчика, мы:
- Соблюдаем процесс разработки и постоянно его совершенствуем. Четкое следование стандартам и практикам, выработанным за 22 года проектной деятельности, позволяет добиваться предсказуемых результатов;
- Уделяем большое внимание аналитике. Чем лучше она проработана, тем ниже неопределенность, меньше багов и несоответствий между конечным решением и видением клиента;
- Обеспечиваем качество. На обеспечение качества наших проектов работает целый комплекс процессов компании: заранее определенный workflow, выстроенные процессы тестирования и т. п.
При этом мы стараемся не слишком зацикливаться на том, чтобы сделать всё идеально и в итоге затягивать сроки, сливая бюджет клиента, — это не в наших правилах. Если продукт устраивает клиента и решает его бизнес-задачу — мы считаем его готовым и завершенным.
Контроль исполнения всех процессов в компании — ответственность службы качества, о специфике работы которой рассказывает моя коллега Екатерина.
Сверяться на промежуточных этапах
На этапе аналитики крайне важно понять реальные бизнес-цели заказчика, снизить функциональную и техническую неопределенность на проекте. Чтобы провести этот значимый этап качественно, мы привлекаем всех необходимых специалистов: аналитика, руководителя проекта, тимлида и QA-лида. После согласования артефактов (технического задания, прототипов, архитектурной концепции и прочего) со стороны заказчика команда приступает к этапу разработки.
Разработку продукта стараемся строить на основе Agile-практик, использовать основные события Scrum. Их цель — как можно быстрее предоставить заказчику нужный результат. В конце каждого спринта проводим обязательную демонстрацию проекта клиенту и ретроспективу. Обсуждаем, с какими сложностями сталкивается команда и что планируем делать для их устранения. Если они возникли из-за ошибок на стороне заказчика — просим исправить, предоставить информацию или выделяем специалиста ему в помощь.
Правильно исправлять ошибки
Как бы качественно и хорошо мы ни делали с самого начала — ошибки неизбежны. Бывают ситуации, когда у заказчика есть определенные ожидания, но где-то происходят разночтения. Во время работы могут открыться неожиданные детали, которых мы не учитывали ранее, но они влияют на ход и результаты проекта.
Каждый такой случай мы рассматриваем как ценный опыт и используем, чтобы улучшить процессы в компании. То есть когда становится понятно, что произошла ошибка, мы сначала в кратчайшие сроки исправляем ее, а потом разбираемся в причинах. Специалисты проводят исследование, находят причины и вносят коррективы в процессы и базу знаний. Так риск подобной ошибки в будущем снижается.
Резюмируем
- Главное — решить задачу клиента. Нужно отталкиваться от нее и предлагать разумное решение, а не выводить заказчика на дорогой и ненужный продукт.
- Общение и сбор информации — важно. Чем больше информации об ожиданиях и требования заказчика смогли собрать, тем лучше. Для этого у нас есть чек-листы с вопросами по продукту, подробные интервью на старте и регулярные созвоны.
- Следим за четким исполнением процессов разработки и постоянно совершенствуем их. В разработке всегда нужно учиться новому, и это касается не только технологий. Поэтому мы совершенствуем процессы после каждого кейса и учимся на малейших ошибках.
При таком подходе и двести проектов одновременно — не предел!
Если у вас есть свои правила, как вести много проектов одновременно, — поделитесь в комментариях!
очень много кому не хватает предсказуемости
работаем с одним подрядчиком, так он может месяц кормить завтраками, потом сделать за неделю и начать кричать: "все готово, ждем только вас, почему не проверяете"
а нам стенд подготовить, потом в спринт включить, нет бы заранее сказать
накипело, конечно)
а бывало такое, что отказываетесь от каких-то проектов? какие обычно причины для этого есть?
Екатерина, добрый день! Как правило, если на этапе оценки мы понимаем, что не сможем гарантировать качественный результат в жестко ограниченные сроки и бюджет, понимая, что на проекте много технической и функциональной неопределенности, мы не возьмемся за проект, чтобы потом не рисковать своей репутацией.
В таких вопросах решение зависит от множества факторов - каждую ситуацию рассматриваем в индивидуальном порядке)
ИМХО: думать о клиенте и выстраивать процессы — взаимосвязанные вещи. Опыт подсказывает, что если компания пытается всем продать одно и то же и самое дорогое, то там скорее всего и процессы будут не очень, и вместо контроля качества ветка)) Ну и наоборот, получается.