iBusiness.ru публикует сокращенную версию статьи Антона Штульберга, впервые размещенной на E-xecutive.ru.
«Первый принцип – это единая команда
Слаженная работа, отсутствие конфликтов внутри команды, взаимопонимание и единое мышление – все это является залогом победы. Если заказчику нужно разработать приложение для нескольких платформ, команда увеличивается, но цель у нас все равно одна: качественное и удобное приложение, которое удовлетворит ожидания клиента.
Для получения максимального результата мы строим единую общую команду, сформированную из специалистов с нашей стороны и стороны заказчика. Нам важно создать команду, в которой все будут знать друг друга и знать, что у нас общая цель – чтобы проект увидел свет в заданные сроки. Помимо этой цели, единая команда позволяет создать продукт, который соответствует задуманному. В процессе работы я должен быть в курсе того, кто за что отвечает, чтобы в различных ситуациях максимально быстро согласовывать решения и улаживать возникающие проблемы.
Второй принцип — управление ожиданиями
Как бы это ни было печально, но статистика такова, что в IT-бизнесе проекты не всегда укладываются в сроки. Бывает так, что на каком-то этапе возникают различные форс-мажоры – от увеличения времени разработки до смены видения какого-либо элемента приложения. И из-за этого приходится отодвигать срок сдачи проекта.
Чтобы избежать конфликтов с заказчиком, он должен узнавать о таких форс-мажорах первым. Для этого раз в неделю мы проводим конференц-коллы, на которых я подробно расписываю этапы работы и показываю то, что уже сделано. Таким образом, если заказчик хочет что-то поменять, нам не приходится переделывать все приложение, мы можем добавить или убрать нужную функцию и, отталкиваясь уже от новой концепции, продолжать работу.
Я доношу все пожелания заказчика до команды и стараюсь сделать так, чтобы процесс проходил гладко.
Третий принцип – личный контакт с клиентом
Личный контакт – это действенный способ построить хорошие отношения с клиентом. Но так как большинство наших заказчиков – это крупные бренды, офисы у которых разбросаны по всему миру, вероятность живой встречи уменьшается. Тем не менее, в начале работы с новым клиентом я всегда стараюсь приехать к нему в офис и познакомиться с ним лично.
Во всех своих проектах я знаю, помимо менеджера проекта, команду разработчиков и сотрудников, которые отвечают за процесс подписания договора. Но личные встречи на этом не заканчиваются. В процессе работы с клиентом мне приходится достаточно часто ездить на встречи, чтобы обговорить детали и обсудить видение проекта. Любой вопрос улаживается быстрее, если это делать лично.
Четвертый принцип – прозрачность работы
Обе команды (и с нашей стороны, и со стороны заказчика) в курсе того, к чему мы идем. Помимо еженедельных скайп-митингов, заказчик отслеживает ход работы в трекере. В любой момент он может мне позвонить и прояснить непонятные для него моменты.
К скайп-митингам может подключиться кто-то из команды. Например, на стадии дизайна обычно отрисовывается не один вариант экрана и для уточнения каких-то деталей, создания идеального внешнего вида приложения, мы проводим несколько часов в скайпе с командой дизайнеров и клиентом.
Один из подводных камней крупных организаций — это согласование любой функции приложения, дизайна иконки или кнопки со множеством людей, начиная от менеджера проекта и заканчивая отделом маркетинга.
Пятый принцип – максимальная гибкость работы
Конечно, в идеале, никаких крупных изменений проекта нет, но в реальной жизни бывает такое, что клиент хочет радикально поменять концепцию приложения или добавить еще шесть новых функций. Поэтому пятым принципом является максимальная гибкость работы. Мы всегда готовы к рассмотрению нового видения и обсуждения нужности введения новых функций.
Этот принцип идет вместе с принципом уменьшения рисков третьих сторон. Как я уже говорил, в IT-бизнесе проекты не всегда укладываются в указанные сроки и именно это влечет за собой срыв не только наших планов, но и планов клиента. Маркетологи со стороны заказчика планируют все свои активности, в том числе и запуск приложения (которое является важным информационным поводом) на год вперед и в случае изменения срока релиза приложения, работа очень многих людей встает.
Все взаимосвязано, как в домино: простой разработчиков влечет за собой отсроченный релиз, из-за этого изменяются сроки выполнения плана на стороне заказчика и в результате срывается весь план.
Заказчик должен знать о рисках и о том, что работа идет. Наша работа не зависит от проблем заказчика (с той же документацией, например), ни от третьих сторон. Если возникают какие-то форс-мажоры, то, пока я их улаживаю, наши разработчики переключаются на другие задачи. Процесс должен идти всегда. Только в этом случае есть вероятность того, что проект будет сдан в срок.
Руководствуясь этими принципами, вы построите с заказчиком отношения, близкие к идеальным. В итоге это поможет вам не только получить качественный результат, но и построить прочные отношения с вашими клиентами, которые, будьте уверены, придут к вам снова».
Автор – Антон Штульберг, руководитель проектов компании e-Legion
Комментарии
*
1. Увеличение времени разработки.
2. Смена видения какого-либо элемента приложения.
Когда у разработчиков возникают эти форс-мажорные обстоятельства, указанный в договоре срок сдачи проекта «отодвигается». Оказывается, чтобы в таких случаях избежать конфликтов с заказчиком, его надо немедленно оповещать об этих форс-мажорных обстоятельствах, как только они возникают.
В пункте 2 явно имеется в виду, что «смена видения» во время реализации проекта происходит не у заказчика, а у разработчиков. Иначе зачем им нужно было бы «первым» оповещать заказчика?
Крайне своеобразная, удивительная интерпретация понятия «форс-мажор». Так и представляю себе договор на ИТ-аутсорсинг с отдельным разделом «Форс-мажорные обстоятельства», где указаны и «увеличение времени разработки», и «смена видения».