ночь
en | ru

#10. Кооперация между Клиентом и Исполнителем. Подводим итоги.

Мы рассмотрели SCRUM фреймворк, роли участников проекта, процессы и используемые инструменты. В этой статье мы взглянем на процесс кооперации между клиентом и компанией-разработчиком. В конце статьи мы подведем итоги и закончим ознакомление с "технической" частью проект менеджмента.

Цель этой статьи в том, чтобы максимально ясно показать структуру IT компании-разработчика, и то, как эта компания функционирует. То, что я описываю здесь – наиболее часто встречаемые практики, однако у любой компании есть своя специфика, где структура, иерархия, роли и обязанности участников могут сильно отличаться.

Прежде всего разберемся с терминологией. Компания, которая занимается разработкой ПО под заказ, называется IT-Аутсорсинговой компанией (IT Outsourcing company). Основной (и обычно, единственный) сервис таких компаний – это аутсорсинг. IT-Аутсорсингом называется процесс, когда некая компания, у которой появляется необходимость в разработке какого-то ПО, находит Аутсорсинговую компанию и делегирует это дело ей.

К примеру, некая компания занимающаяся финансовыми консультациями (далее Фин. компания) в какой-то момент вырастает и понимает, что ей нужны специализированные приложения, помогающие удобнее вести запись данных клиентов. Фин. компания сперва изучит рынок, и готовые предложения, ведь они не первые у кого возникла потребность что-то автоматизировать/оцифровать. Если в результате поиска они не найдут удобного готового решения, они могут решить заказать собственное ПО у аутсорсинговой компании. В идеале, они составят документ описывающий функции которые хотели бы видеть в приложении, и проблемы, которые это приложение должно решить. Этот документ называется RFP (Request For Proposal, Запрос Предложения) и к его составлению, помимо профильных специалистов, привлекают также технических специалистов. Делается это для того, чтобы требования в документе были исполнимы (ведь профильные специалисты иногда понятия не имеют, что возможно, а что - нет). Затем, этот документ отправляется аутсорсинговым компаниям, вместе с крайним сроком рассмотрения и запросом стоимости (Иногда, стоимость выставляется самим клиентом, но это бывает редко).

Аутсорсинговые компании получают документ и начинают анализ требований и оценку стоимости. Практически всегда у них возникают вопросы, которые необходимо уточнить. Посудите сами: если даже в одной маленькой User Story грамотный специалист может допустить ошибку, то очевидно, что в документе состоящем из десятков (а то и сотен) будет полно ошибок и нестыковок.

Итак, компания собрала вопросы и направила их Клиенту. Клиент прислал уточнения и аутсорсинговая компания наконец-таки все проанализировав отправила свое Предложение (Proposal) Клиенту.

Клиент получил предложения, подумал и выбрал аутсорсинговую компанию, с которой будет работать. Основным фактором для клиента на данном этапе являются время и стоимость. Мы не говорим о качестве ПО, т.к. его невозможно объективно оценить. Поэтому, часто, клиент просто верит, что с качеством проблем не будет, полагаясь на отзывы тех, кто уже имел дело с этой аутсорсинговой компанией.

Альтернатива отзывам - это оценка аутсорсинговой компании по их примерам работ (портфолио компании), но это тоже очень рискованно.

Дальше компания отправляет своего Бизнес Аналитика чтобы вникнуть в бизнес нашего клиента еще больше и так далее. Мы об этом уже говорили в статье "Что такое проект?"

Тип 1:

/assets/images/10-1.jpeg

Здесь, справа налево мы видим CEO компании “PlumbusSoft” LLC, которая занимается IT-аутсорсингом.

Ему подотчетен Менеджер Проекта (PM), который находится в постоянном контакте с Тимлидом (и, если есть, Бизнес Аналитиком / Владельцем Продукта, который является сотрудником его же компании).

Тимлид в свою очередь координирует команду, которая, как правило, состоит из разработчиков, дизайнера и тестировщиков. В некоторых случаях один или несколько участников команды могут работать удаленно, однако, очевидно, это потребует дополнительных усилий в планировании и координации (особенно, если удаленно работающие участники не в нашем часовом поясе).

С левой стороны, на картинке мы видим Владельца Продукта (Product Owner, PO), который является сотрудником компании клиента. Его ключевая обязанность, - это координация деятельности команды работающей над проектом и помощь в постоянно возникающих вопросах. Эта координация осуществляется согласно заранее обговоренному протоколу (Звонки по скайпу, чаты, имейлы, совместное написание Историй и так далее). PO всегда является тот человек, у которого есть прямой выход на вышестоящее руководство, непосредственных заказчиков продукта, конечных пользователей продукта и всех тех, чья помощь может понадобится при разработке. Помимо всего этого, PO должен разбираться в нюансах разработки ПО достаточно, чтобы понимать грань между рациональным и излишним. Если в компании нет Product Manager-а, тогда PO должен обладать правом принимать все ключевые решения по продукту ибо в противном случае, от него мало пользы. Короче суть в том, что нахождение грамотного PO – это действительно очень, очень сложная задача. Конечно, речь идет о качественном PO, тогда как просто «сертифицированного» PO с кучей грамот и хвалебных писем можно найти на раз-два ☺.

Вернемся к нашей картинке. Практически всегда аутсорсинговая компания занимается гораздо больше, чем одним проектом одновременно. При этом, компании часто прибегают к экономии и получается что-то типа этого:

Тип 2:

/assets/images/10-2.jpeg

Подобные сетапы используются исключительно чтобы сэкономить. Тимлиды, как и PM-ы являются дорогим ресурсом. Вдобавок к этому, у PM-а работающего над одним проектом часто может появляться свободное время, которое как-раз таки и использует руководство, назначая его работать сразу на два, три а то и больше проектов за раз. Тимлиды, как ресурс более ограниченный, обычно приставляются к одному проекту как к основному и паре-тройке других в роли консультанта. Конечно, это не нормально. Я работал параллельно над 5+ проектами исполняя одновременно несколько ролей в каждом (Это не весело и в этом мало хорошего).

По мере того, как компания разрастается, в какой-то момент она нанимает Менеджера Программы (Program Manager, PrM) (либо, чаще, просто повышает одного из своих PM-ов).

Если Менеджер Проекта отвечает за ход, сроки, бюджеты и ресурсы, то Менеджер Программы отвечает за группу проектов аутсорсинговой компании. В его обязанности входит координация этих проектов так, чтобы их сроки завершения и бюджеты соответствовали краткосрочным и долгосрочным целям компании. Менеджеру Программы подотчетны все PM-ы чьи проекты находятся в портфеле PrM-а.

Взглянем на пример грамотного, простого сетапа.

Тип 3:

/assets/images/10-3.jpeg

Здесь как мы видим у компании уже три крупных проекта, и Менеджер Программы, который координирует их менеджеров. Приставка «Web Division» здесь не случайна. Множество аутсорсинговых компаний предоставляют сервис разработки мобильных приложений, поэтому часто, постепенно разрастаясь, в структуре компании появляются Менеджеры Программ отдельных дивизионов занимающихся только какими-то конкретными типами проектов.

Тип 4:

/assets/images/10-4.jpeg

На этой картинке у нас добавился Менеджер Программы ответственный за проекты разработки мобильных приложений. Также вы можете заметить DevOps-специалиста, которого я забыл добавить на предыдущие картинки. Все потому, что DevOps-ы работают молниеносно и незаметно ☺.

Последней картинкой мы добавим несколько ролей, которые, однако, присутствуют только в очень крупных компаниях, размеры которых исчисляются сотнями/тысячами сотрудников.

Тип 5:

/assets/images/10-5.jpeg

Когда у компании огромное кол-во проектов, на сцену выходит Senior Program Manager. Из названия становится очевидно, что он в ответе за братьев своих младших – PrM-ов. Именно он координирует крупные рабочие сферы компании так, чтобы все соответствовало поставленным целям высшего руководства. Непосредственно над ним находятся COO (Chief Operating Officer – Главный Операционный Директор), CEO а также, в некоторых случаях, партнеры компании и другие ключевые заинтересованные лица компании.

Теперь мы подведем итоги и закончим «техническую» часть менеджмента этой главой.

Итоги

Давайте выведем списки того, с чем мы успели ознакомиться, а что выпало за рамки этого материала.

О чем мы не поговорили, но я рекомендую об этом почитать (вдаваться в детали на первых порах не нужно, просто загуглите и пройдитесь):

Что гуглить чтобы стать умнее:

  • Наиболее популярные языки программирования. Какие языки для какого типа приложений в основном используются;
  • Кто такой фронтенд, бэкенд и фул-стэк разработчик, и какая между ними разница;
  • Ключевые отличия между джуниором, мидом и сениором применительно ко всем ролям о которых ме успели поговорить;
  • Непрерывная интеграция, непрерывная доставка, непрерывное развертывание;
  • Стоимость разработки приложений на вашем локальном рынке а также отдельно – на зарубежном (обычно указывается в человекочасах);
  • Не смотря на то, что во многих книгах и статьях посвященных управлению проектами менеджеры очень часто говорят о таком понятии, как MVP (Minimal Viable Product), я умочал о нем намеренно, так как считаю, что MVP, это термин/подход, который скорее связан с управлением продуктом, нежели проектом.

Что читать чтобы стать умнее:

  • Мортимер Адлер – Как читать книги;
  • Джона Лерер – Как мы принимаем решения;
  • Эндрю Стеллман - Постигая Agile;
  • Уильям Голдратт - Теория ограничений;

Напоследок можете пройтись по Project Management Institute PMBOK (Можете бегло окинуть взглядом этот кладезь информации мертвым грузом лежащей в этой вечно обновляемой книге, чтобы знать как нельзя составлять книги.)

Да, по книгам получилось негусто, но к сожалению почти все что я читал и читаю не имеет прямого отношения к менеджменту, а то, что имеет – на мой взгляд, написано слабо и может, разве что запутать ☹.

А вот то, о чем мы успели поговорить и понять:

  • Что такое проект, и как идея становится проектом, в частности нами были затронуты следующие вопросы:
    • Что такое идея;
    • Что такое схема;
    • Что такое документация;
    • Что такое эскиз;
    • Что такое макет;
    • Что такое прототип.
  • Какие артефакты и особенности есть в IT-проектах;
    • Что такое эпик;
    • Что такое пользовательская история;
    • Что такое задача;
    • Что такое под-задача;
    • Что такое баг.
  • Из чего состоит рабочая среда участников IT-проектов;
    • Как решается вопрос координации;
    • Как решается вопрос коммуникации;
    • Как решается вопрос обмена файлами.
  • Какие философии и методологии управления проектами существуют и какова разница между этими понятиями;
    • Определение науки;
    • Определение философии;
    • Определение методологии;
    • Определение фреймворка;
    • Использование вышеуказанных определений в IT-проектах;
    • Использование фреймворков;
      • Канбан-метод;
      • Скрам;
      • И другие.
  • Какие циклы и подходы к разработке программного обеспечения существуют и чем отличаются;
    • Прогнозируемый подход;
    • Итеративный подход;
    • Инкрементальный подход;
    • Agile подход;
    • Разбор принципов Agile.
  • Работа со Скрам фреймворком;
    • Артефакты Скрам;
    • Ритуалы Скрам;
    • Роли участников проекта;
    • Скрам-роли участников проекта;
    • Ключевые ценности Скрам.
  • Схема принятия и ведения проекта. Кто с кем контактирует и через какие этапы проходит проект;
    • Анализ требований;
    • Разработка первичной документации;
    • Создание эпиков;
    • Приоритизация эпиков;
    • Пользовательские истории;
    • Оценка пользовательских историй и что такое велосити;
    • Составление бэклога спринта;
    • Ретроспективный анализ;
  • Пользовательские Истории. Как они составляются и из чего обычно состоят.
  • Технические детали, которые очень желательно знать менеджеру;
    • Что такое сервер;
    • Что такое хостинг;
    • Что такое промежуточный сервер;
    • Что такое база данных;
    • Что такое системы тестирования, мониторинга и аналитики и зачем они нужны.
  • Как происходит кооперация между Клиентом и Аутсорсинговой компанией.

С точки зрения фундаментальных знаний, материала, выложенного в этом блоге, более чем достаточно. Теперь вам будет проще решить какие книги читать далее. Вы с самого начала будете знать какие именно знания вы совершенствуете и где они могут быть использованы в менеджменте. Закрепив материал по которому мы прошли, вы уже в самом начале вашего карьерного пути станете замечать, что множество специалистов с годами а то и десятками лет опыта не понимают структуры и оперируют очень простыми, примитивными и, часто, ошибочными понятиями и идеями. Причина этого невежества, по моему глубокому убеждению – наше эго, которое не позволяет нам развиваться, и вместо этого «принуждает» нас получать удовольствие от нашего «высокого» положения. Наше эго кормит нас маленькими успехами, не позволяя задуматься о том, что бы могло быть если бы мы поставили перед собой огромные, великие цели. Собственно, именно понимание этого стало причиной того, что я решил написать эти статьи.

Большинство книг которые вы прочтете уместились бы в 30-60 страничной брошюрке, однако, никто из авторов не пойдет на это, потому что в такой брошюре не поместится вся та помпезность и бесконечная вуалированность терминов, которыми сей автор хочет показать свою профессиональность и знание дела.

Не ведитесь на понты и старайтесь всегда быть проще и ближе к простым людям, коими все мы являемся.

На этом серия «технических» статей завершается.

В следующей статье я расскажу о карьерном пути менеджера и дам несколько постоянно актуальных советов.