7 факторов успешного IT-проекта
Бизнес требует IT-решений — мобильных приложений, клиентских CRM и других разработок. Как сделать продукт успешным? Что выгоднее: аутсорсинг IT или работа своими руками? Мы в компании SimbirSoft сформулировали 7 факторов успешного IT-проекта, исходя из многолетней практики.
Чем полезен IT-аутсорсинг
Инновации делают бизнес конкурентоспособным и, как следствие, более доходным. В эпоху цифровой трансформации уже не стоит вопрос — делать или не делать, никого не нужно убеждать в том, что IT-преобразования жизненно необходимы. Чаще предприниматели задумываются о другом: какими силами реализовать проект — своими или чужими? Поручить разработку и внедрение внутренним специалистам или нанять IT-компанию?
Сегодня заказчики IT-услуг уже осознают главные преимущества аутсорсинга — доступ к передовым технологиям разработки, концентрация на собственных бизнес-задачах и, конечно, скорость реализации проекта. В нашем мире время стоит дорого. Любой сбой или ошибка — это потеря времени, которая может дать фору конкурентам.
Иногда счет идет буквально на дни! Рынок выигрывает тот, кто первый предложит клиентам новый сервис или удобное мобильное приложение. И в этой ситуации свежий, незамыленный взгляд стороннего разработчика может оказать неоценимую услугу.
Из практики:
Например, одному крупному российскому банку мы помогли улучшить систему взыскания просроченной задолженности. Заказчик пришел к нам с готовым техническим заданием, которое он написал самостоятельно, ориентируясь на требования Федерального закона № 230-ФЗ “О защите прав и законных интересов физических лиц при осуществлении деятельности по возврату просроченной задолженности”. Наши специалисты проанализировали планируемый продукт и пришли к выводу, что систему можно сделать более гибкой и эффективной (при этом соблюдая 230-ФЗ). В частности, закон ограничивает максимально допустимое количество звонков в сутки, но если клиент не взял трубку, то этот звонок можно не учитывать. Мы предложили заказчику вместо звонков фиксировать в CRM контакты с клиентом — получили одобрение (и благодарность за подсказку!) и приступили к работе. Быстро разобраться в ситуации помог коллективный опыт: у нас были специалисты, которые ранее работали в банковской сфере и знали все нюансы, связанные с дебиторской спецификой.
Фактор успеха #1 — правильно сформированная команда
Подбирать состав исполнителей нужно в соответствии с задачами и сферой деятельности клиента. Опыт каждого члена команды должен соответствовать контексту проекта — индустрии, сегменту, специфике бизнес-задачи и особенностям продукта. Чем глубже каждый участник погружен в тематику проекта, тем меньше риски упустить нечто значимое и важное. Так, например, при создании системы безопасности для одной крупной клиники мы задействовали экспертов по нескольким направлениям — администрирование медицинских учреждений, информационная безопасность, аутентификация личности и т.д.
Из кого обычно состоит проектная команда?
Для крупных проектов мы задействуем большую команду:
- аккаунт-менеджер (AM)
- проджект менеджер (PM)
- team-leader (TL)
- специалист по оценке качества (QA)
- аналитики
- разработчики.
Основная задача проджект-менеджера — сдать качественный проект, соблюдая отведенные сроки и бюджет, на особо крупных проектах он может управлять несколькими командами. Аккаунт-менеджер выстраивает отношения с клиентом, он может поддерживать беседу на “нормальном человеческом” языке и разбирается в продуктах. Аккаунт транслирует стратегические приоритеты клиента проджект-менеджеру, а тот формулирует задачи команде, которой руководит технический специалист — team-лидер. Аналитики понимают специфику разных индустрий и прорабатывают бизнес-требования. А разработчики на основе этих требований реализуют уникальные технически сложные задачи.
За спиной у каждого PM-а в нашей компании — десятки реализованных проектов в разных отраслях (банкинг, медицина, ритейл и т. д.) и не менее пяти лет стажа в сфере управления проектами. Чем больше проектов в компании выполняется одновременно, тем больше нужно менеджеров и разработчиков. У нас, например, параллельно реализуется порядка 60 проектов, над которыми трудятся более 500 специалистов.
Фактор успеха #2 — «не продуктом единым»
Знать все технологические тонкости и нюансы продукта, мыслить “продуктово” — очень важно и правильно, но настоящий специалист пойдет дальше и глубже — в сферу развития бизнеса. Как бы нам, айтишникам, ни хотелось превознести свою значимость, всегда нужно помнить одну простую истину: IT-система — это не самоцель, а средство достижения цели. Истинная цель лежит не в сфере технологий, а в сфере бизнеса.
Иногда заказчики приходят к нам с уже разработанным планом действий, выдавая за цель готовое решение. Как быть?
Вариант 1: брать и делать, исходя из аксиомы «клиент всегда прав». Вариант 2 : сделать шаг назад и убедиться в том, что именно это решение нужно клиенту. А для этого нужно ответить на самый главный вопрос — зачем? Какова цель? Почему созрело решение внедрять то или иное ПО? В силу своего опыта мы привыкли все перепроверять. Практика показывает, что такая «дотошность» может оказаться полезной.
Из практики:
Один региональный банк пришел к нам со следующей задачей: внедрить приобретенное им коробочное ПО. Это было мобильное приложение для дистанционного банковского обслуживания физических лиц. Согласиться “не глядя” и пойти считать бюджет — не наш метод. И мы стали выяснять — а какова бизнес-цель? Почему именно сейчас потребовалось начать внедрение?
Оказалось, что одна из приоритетных бизнес-задач заказчика на ближайшую перспективу — войти в ТОП-10 банков, предлагающих пользователям лучшие мобильные приложения (рейтинг составляется на основе целого ряда критериев). И эта задача — одна из ступенек на пути к достижению самой важной стратегической цели: выйти на принципиально новый уровень и стать большим федеральным банком.
Мы тщательно изучили рейтинг и все его требования, после проанализировали закупленное коробочное решение (а также существующие рыночные аналоги) и поняли, что у него есть серьезные недостатки. Типовая «коробка» не подстраивается под текущие бизнес-процессы банка, а значит, ее нужно переработать, чтобы и по быстродействию, и по функциональности приложение соответствовало всем необходимым критериям. Стали искать оптимальный вариант: погрузились в бизнес-процессы, собрали фокус-группу, изучали поведение конечных пользователей, в общем, ставили эксперименты на себе, как Луи Пастер. В итоге нашли решение и презентовали его заказчику. Проект был реализован за несколько месяцев, а через полгода после его завершения банк вышел на четвертое место в том самом важном для него рейтинге.
Фактор успеха #3 — определить объективные ограничения и барьеры для реализации проекта
Есть такие заказчики, которые все хотят сделать идеально, видят продукт только с богатой функциональностью и не готовы идти на компромиссы. Начиная проект, они планируют расширить возможности системы до максимума без оглядки на сроки и бюджет. Для исполнителя такой клиент — подарок судьбы. Соблазн ответить «да» и побежать выполнять, конечно, велик. Но при таком подходе есть много рисков. Риск №1: потерять приоритеты и в итоге сделать совсем не тот продукт, который нужен заказчику. Риск №2: не уложиться в сроки.
Из практики:
Приведу конкретный пример: мы начали проект, масштаб работы был внушительный, мы не успевали записывать за заказчиком все его пожелания и идеи. Но мы прекрасно понимали, что одну функциональность можно сделать за неделю, а на другую и месяца не хватит. Выяснили бизнес-цели и сроки. Оказывается, что ровно через четыре месяца нужно показать прототип системы инвестору для получения следующего транша. Дали обратную связь и объяснили, что дополнительные возможности системы в этот срок никак не вписываются. Мы предложили сосредоточиться на самых важных задачах, а развивать продукт — уже когда будут готовы основные модули системы. Аргументированно объяснили, почему нужно сократить то-то и то-то, чтобы уложиться в срок (например, привели статистику по функции, которая используется крайне редко). Расставив приоритеты, мы получили «добро» и реализовали проект в срок. И уже после этого перешли к плановому совершенствованию продукта в соответствии с новыми задачами.
Любое дополнение к базовой функциональности должно быть обосновано — расчетами эффективности, сроками реализации, конкретной пользой для бизнеса.
Фактор успеха #4 — снятие страхов и опасений
Иногда препятствием на пути хорошей идеи могут стать сомнения ее автора. Бывает, что у инициатора проекта мало опыта, и он не понимает, как правильно «продать» свою идею руководству. Или специалист горит идеей, искренне хочет что-то улучшить, но не знает, как именно это сделать. И тогда он приходит со своей идеей в IT-компанию и просит проработать ее и оценить масштаб “бедствия”. Дальше есть два сценария. Первый — обрадоваться и посчитать бюджет, развив идею до уровня «новых Васюков». Второй — выбрать небольшую, но значимую функциональность и разработать ее до уровня программного продукта, не замахиваясь на преобразования вселенского масштаба. Мы предпочитаем второй путь, потому что он реалистичный. Во-первых, это не займет много времени: на разработку небольшой части уйдет не больше месяца, и за этот срок инициатор проекта не успеет «перегореть», томясь в ожидании. Во-вторых, бюджет и масштабы грядущих преобразований будут меньше, а шансы получить одобрение и зеленый свет от руководства — намного больше.
Из практики:
Хорошо помню наше знакомство с HR-специалистом одной компании, который придумал очень полезную вещь: он предложил сделать внутреннее приложение для сотрудников, чтобы каждый из них в реальном времени мог видеть свои KPI, планы действий, бонусы и т. д. Это приложение, по его замыслу, должно было стать важным элементом мотивационной программы для персонала. Однако, он не знал, как это должно быть реализовано на практике, сколько может стоить подобный проект.
Вместе мы описали все бизнес-процессы для этого приложения, но выбрали только одну значимую функциональность и проработали ее в урезанной версии. Отрисовали макеты и экраны, оценили первый этап и прописали план развития продукта в случае успешного тестирования. Менеджер презентовал идею директору, тот заинтересовался и одобрил первый этап. В итоге проект был реализован целиком и продолжает развиваться. А его инициатор и руководитель получил повышение.
Фактор успеха #5 — уважение к коллегам и выстраивание оптимального взаимодействия
Недавно я пришел стричься к новому мастеру, и тот, критически оглядев мою голову, спросил, что за неопытный студент стриг меня в последний раз. Знакомая ситуация? Ни один сантехник не упустит возможности посетовать на неправильно закрученную кем-то до него гайку, а строитель — на криво приклеенные его предшественником обои. Что следует за этим? Конечно же, предложение все переделать наилучшим образом! Часто так бывает и в IT-бизнесе, особенно если коллеги по цеху дают повод для критических замечаний. В нашей практике был случай, когда нас пригласили включиться в проект, на котором уже работал другой подрядчик. Проект давал сбой. Сроки не соблюдались, ошибки вовремя не исправлялись, в общем, заказчик был недоволен и хотел каким-то образом проблему решить. В такой ситуации велико искушение «добить» конкурента и перетянуть одеяло на себя. Но тогда все придется начинать целиком, а это означает новые сроки и новые бюджеты. Погрузившись в контекст, мы выяснили природу ошибок и возникших проблем. Оказалось, что у текущего подрядчика не хватало специалистов нужного профиля в реализации front-end задач.
В итоге мы поделили фронт работ и часть модулей взяли на себя, подключили нужных специалистов, что позволило выявлять дефекты на ранних стадиях и экономить время на переделках. А заодно придумали способ ускорить реализацию проекта. Изначально участники проекта работали последовательно. Дизайнеры ждали, когда закончат работу аналитики, и только после этого брали в отрисовку все необходимые макеты и экраны. Закончив работу, дизайнеры передавали эстафетную палочку верстальщикам. Мы сменили последовательный формат работы на параллельный. В итоге аналитик отправлял дизайнеру на отрисовку экраны по мере их готовности, не дожидаясь, когда будут готовы все 25 штук. И тут же начинал делать следующую партию. Срок разработки уменьшился в два раза, и проект общими усилиями был завершен в запланированные сроки.
Фактор успеха #6 — формирование доверия и правильные коммуникации
Правильная команда — необходимый, но недостаточный фактор успеха ИТ-проекта. Даже специалист мирового масштаба не добьется результата, если не сможет выстроить с клиентом нормальные доверительные отношения. Некоторые люди всю жизнь испытывают сложности с коммуникациями, поэтому могут ухмыльнуться и воспринять этот совет с большим скепсисом. Но на самом деле все просто. Никаких секретных правил и тайных знаний. Первый шаг — это погружение в контекст клиента, все, о чем мы говорили выше. Цель, задачи, барьеры, ограничения, страхи, опасения, предыдущий опыт — не стесняйтесь копать как можно глубже, выясняйте по максимуму. Этим вы не нарушите границы и не будете уличены в попытке прорваться на запретную территорию. Ровно наоборот — вам будут признательны за ваш неподдельный интерес и желание взять часть ответственности за результат на себя.
Второй шаг — это контроль коммуникаций. Его тоже надо брать на себя. Ни в коем случае нельзя погружать клиента в информационный вакуум. Важно все: созвоны, отчеты, демонстрации раз в месяц, если требуется, встречи на территории клиента и т. д. Мы в компании всегда сами организуем коммуникации и контролируем их, чтобы клиент не тратил на это время. Если мы будем ждать от него обратной связи, а не брать инициативу на себя, проект может застопориться.
Фактор успеха #7 — развитие вместо поддержки
Стандартный вопрос любого заказчика: а вы поддержку оказываете? И стандартный ответ: конечно, оказываем! Это делают все. Мы сфокусированы на том, чтобы это была не просто поддержка, а полноценная стратегия развития. Продукт не может оставаться статичным — чтобы приносить результат, он должен находиться в динамике. На самом деле, проекты с ограниченным сроком действия вообще встречаются редко (ну, разве что, некий продукт выпущен к Чемпионату мира по футболу — а он еще долго не повторится в нашей стране!).
Всегда нужно держать руку на пульсе: анализировать рынок, мониторить конкурентов, изучать новые тренды, предлагать новые версии и варианты развития. Другими словами — с головой уйти в жизнь продукта, не ограничиваясь формальными сроками разработки. Любому заказчику важно быть уверенным в том, что его не бросят, что созданная система будет жить и развиваться. Правильный исполнитель отвечает не только за конкретный результат, но и за всю систему жизнеобеспечения созданного им продукта.
Для справки:
Глобальная компания SimbirSoft с 2001 года предоставляет услуги по разработке программных продуктов на заказ для организаций из России, США, Германии, Великобритании, Австралии, Японии, Швейцарии. Среди клиентов SimbirSoft банки, финансовые и страховые организации, телекоммуникационные компании и международные холдинги.
