keepsimple
dark
en | ru

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

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

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

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

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

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

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

Клиент, получив предложения от разных компаний поразмыслил, и выбрал наиболее подходящее, где соотношение цена-сроки его устроили (Заметьте, мы не говорим о качестве, так как объективно оценить его бывает крайне сложно, и в основном приходится полагаться на опыт тех, кто уже имел дело с этой компанией ранее.

Портфолио компании – это отдельная тема, и полностью полагаться на него тоже бывает очень рискованно).

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

Тип 1:

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

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

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

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

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

Тип 2:

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

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

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

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

Тип 3:

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

Тип 4:

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

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

Тип 5:

Когда у компании огромное кол-во проектов, на сцену выходит 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 страничной брошюрке, однако, никто из авторов не пойдет на это, потому что в такой брошюре не поместится вся та помпезность и бесконечная вузалированность терминов, которыми сей автор хочет показать свою профессиональность и знание дела.

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

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

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