Наверх ▲

Управление проектами в 4-х производственных контекстах

Денис Бесков Денис Бесков Тренер, консультант, организатор "With a Little Help from My Friends".
4.production.contexts бесков
View more presentations from Ontico

 

Денис Бесков: Я впервые на этой конференции. Вижу много лиц – это очень приятно. Надеюсь, сегодня наш с вами разговор будет взаимно интересным. 

О чем сегодня пойдет речь.

Кто я такой. Небольшое введение (буквально один слайд), чтобы вы лучше понимали, какой у меня бэкграунд, о чем имеет смысл меня спрашивать, о чем не имеет смысла спрашивать. 

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

 

Обо мне. 

Как уже сказал ведущий, десять лет разработки ПО. Я начинал разработчиком баз данных на "Oracle". Потом через какое-то время это надоело. Я работал аналитиком, архитектором. Последние два с половиной года работал руководителем отдела анализа в "Лаборатории Касперского". 

PM никогда не был. Но как вы догадываетесь, аналитик – это всегда правая рука PM. Человек, который помогает снижать риски проекта за счет работы с требованиями, разработки требований (возможно, еще моделирования). Наблюдал много проектов в разных компаниях. За всю историю своей работы я поработал, наверное, в десяти компаниях.

Сейчас мне наиболее интересна тематика управления программными продуктами в России. Я вижу, что у нас в индустрии очень плохо с этой тематикой, очень мало экспертизы. Не так много продуктов мирового и локального уровня. Я вижу очень большой потенциал в том, чтобы эту индустрию развивать. 

Есть мой сайт. Можно зайти будет потом – при желании почитать какие-то более подробные презентации, пре-, пост-конференции, статьи, новости и так далее. 

Почему такая тема.

Из моего опыта работы в индустрии следует, что все-таки есть такое понятие как заказная/не заказная разработка, продуктовая/не продуктовая. Об этом так или иначе люди говорят, упоминают в своих диалогах. Но периодически я слышу разные куски технологических и управленческих обсуждений, где этот контекст не задевается. 

Да, люди пытаются спорить, друг друга в чем-то убеждать (в каких-нибудь вопросах), а потом выясняется, что они происходят из совершенно разных контекстов. У них, грубо говоря, разные установки, разные цели, разные даже ценности. Бывает такое: "мы работаем на клиента" или "мы работаем на рынок". 

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

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

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

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

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

Есть книги, литература: всякие PMbok, RUP и прочее. Они упорно эту тему игнорируют. Говорят: "У нас есть RUP, есть понятие заказчика. В принципе, это применимо к любому проекту". 

Моя практика показывает, что не совсем так. Есть вещи, где RUP более применим и где RUP менее применим по определенным причинам. Есть определенные куски реальности, которые RUP вообще не затрагивает. 

Например, там есть такое понятие, как контракт. 

Контракт – ключевое понятие для заказной разработки. В продуктовой разработке оно смысла не имеет никакого. Во внутренней разработке тоже смысла не имеет никакого. Тем не менее, RUP этот контракт всеми сторонами обходит, о нем ничего не говорит, хотя для заказной разработки он больше всего предназначен. 

Я сейчас сделаю введение в терминологию. 

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

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

Есть люди – инвесторы, владельцы бизнеса – которые заинтересованы в получении прибыли. Они заинтересованы в устойчивости бизнеса, получении и росте прибыли. Это интерес бизнеса. 

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

Есть пользователи, которые эту систему используют в работе либо в быту. Извлекают из этого какую-то выгоду для себя либо для бизнеса. 

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

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

Что здесь важно.

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

Еще один слайд из общих принципов: что важно, на наш с коллегами взгляд, при рассмотрении проектов и в производственной деятельности. Важно, что есть проект и есть его результат. 

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

С точки зрения результата мы немножко специфически делим результат на две части. 

•Объем (то, что касаемо scope).

•Качество.

Эти вещи часто неразрывно связаны, очень тяжело отделимы. В то же время мы считаем полезным отделять качество как некое соответствие результата ожиданиям от формального набора свойств результата, которые представлены где-то в ТЗ, в контракте, где-то еще, (неразборчиво) документации. 

Есть такое уравнение. Формально оно не особо математическое. Но, на мой взгляд, наглядное. 

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

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

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

Вот такая терминология. Если что-то будет непонятно, я на какие-то вопросы отвечу по ходу – можно задавать вопросы. 

Начинаем мы с первого контекста. Он, как мне кажется, один из наиболее простых в каком-то смысле. На самом деле – со своими сложностями. Он простой по системе, по структуре. Но достаточно сложный с точки зрения эффективности работы. 

О чем идет речь.

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

Люди находятся в одной организации. Если организация небольшого масштаба – какая-нибудь современная, молодая – то обычно внутренние границы как таковые не очень чувствуются. Есть, может быть, отделы, подразделения, департаменты – но границы могут быть условными. 

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

Это же порождает определенные проблемы. Очень часто внутренние разработки (особенно если мы говорим не про IT-компанию, а про классическую бизнесовую компанию типа FMCG либо "Нефтегаз"),  проектные инициативы по разработке, доработке, изменению систем не имеют четкого адресата, четкого бизнес-заказчика и цели. А есть некоторый набор инициативных людей, которые каким-то образом донесли свои идеи до разработки, и эти идеи стали для нее основой. 

Поэтому я здесь пишу, что типовые цели зачастую бывают смешанные. 

Либо хотят повысить удобство интерфейса без всякой связи с бизнес-эффектом. Либо хотят апгрейдить технологию. Приходят технологи и говорят: "Мы хотим перейти на новый (неразборчиво) сервер, потому что это нам удешевит эксплуатацию и разработку". – "Во сколько точно?". – Ну, мы не бизнесмены – мы вам не оценим. Но надо делать точно, потому что через полгода будет совсем все плохо".

Бывает такое, что если у компании есть бюджет, и бюджетом управляют не очень жестко, потому что компания богатая или успешная, стабильная (там так принято и сложилось), то вполне себе бюджет может быть потрачен на такого рода проекты без какого-либо серьезного учета рентабельности.  

Бывают разные проекты. Например, когда все-таки бизнес выступает заказчиком. Например, в режиме VIP. Говорится, что вице-президент компании хочет видеть такую-то информацию у себя на рабочем экране через такое-то время с такой-то периодичностью. Этого обычно бывает достаточно, чтобы сделать проект. Почти с любым бюджетом его выполнять и завершать.

По поводу ключевых атрибутов. Мы называли на предыдущих слайдах, что есть V > Q > C > T. Это ключевые атрибуты проекта. Здесь построен вектор. Это упорядочение, приостановка, которая говорит о чем. С точки зрения моего опыта практики в индустрии, чаще всего для проекта, для заказчика, ключевых лиц наиболее важен Объем (V): что именно мы сделали. Мы сделали те вещи, которые были нужны, запрошены людьми.

На втором месте стоит качество (Q). Качество как некое соответствие ожиданиям. Допустим, мы сделали те или иные фичи, те или иные (неразборчиво) интерфейсы, процедуры миграции, но потом выяснилось, что заказчик чем-то недоволен. Во внутренней разработке это бывает достаточно важно. Это обычно плохо мониторится, плохо управляется. Тем не менее, это бывает важным. 

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

Поэтому я говорю: деньги могут считаться плохо, а еще хуже считается время. 

Это предложение дискуссионное – не скажу, что везде оно так и только так. Может быть, у вас другая практика. Об этом тоже будет хорошо поговорить. Наверное, лучше в кулуарах. 

Уравнение рентабельности такое же, как и общее уравнение. Здесь единственное: стоит уточнить еще раз, почему здесь стоит знак равенства, почему все-таки выгода не должна быть однозначно больше, чем некоторые вложения и затраты. 

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

Фактически делается разработка рентабельная только до точки, чтобы не получить штрафы. Эта разработка должна быть настолько объемной, емкой и денежной, насколько потенциально опасные штрафы. Вполне себе рациональный есть довод, что вложения могут быть совсем не какими-то супер окупаемыми. 

Как видится задача PM в этом контексте. Что он делает. 

Прежде всего, он работает на бизнес-заказчика внутри компании и управляет его ожиданиями. Он это может делать разными способами. Может писать формальное ТЗ. Может создавать всякие модели бизнес-процессов. Может нарисовать макеты на экране, делать прототипы. 

Это очень сильно зависит от культуры компании, от того, какой менеджмент (IT-шный/ не IT-шный), как они привык слушать аргументы, как он воспринимает информацию, чему он больше верит и почему. 

PM, в основном (как мне кажется), занимается тем, что управляет ожиданиями заказчика. А также отвечает за соответствие хода результатов проекта этим ожиданиям. Достаточно часто к этому примешивается еще работа с ожиданиями пользователя. Потому что пользователи зачастую имеют сильное влияние на заказчика. 

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

•Следующий слайд про то, что со всем этим делать. 

•Как это все оборачивается на практике и что с этим делать. 

•Какие бывают типовые риски проектов в таком контексте – во внутренней разработке. 

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

Очень часто бывает такое, что меняют заинтересованное лицо. Прибегает в ходе проекта какая-нибудь очередная "тетя Маша из бухгалтерии" и говорит: "Вообще все надо делать по-другому, потому что здесь так плохо". Разработка зачастую может повернуть в другую сторону – радикально или не радикально. 

Из-за того, что меняются заинтересованные лица, периодически меняются ожидания и формально не ведется учет требований – так же меняются рамки продукта. Понятное дело. Это автоматически влечет за собой превышение бюджетов и сроков. Мы начинаем вползать за ограничения, которые могли существовать – за разумные ограничения по времени и бюджетам. 

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

Еще есть такой момент как "золочение". Разработчик может быть часто предоставлен сам себе. Почему он пишет ту самую ERP-систему пять лет – потому что он хочет написать ее так, как он хочет сам. У него есть некое видение того, какой должна работать система, универсальный конструктор, глобальная шина. Он эту шину пишет два с половиной года. Потом говорит: "Все остальное мы быстро накидаем на конструкторе за 2 месяца". 

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

Есть ряд рекомендаций, что делать со всей этой ситуацией. Как вообще можно эту ситуацию улучшать.

Так как у нас нет контроля за нормальными сроками и за бюджетом, один из вариантов – уводить всю IT-разработку на подряд, наружу, в аутсорсинг. 

Другой вариант. У нас он использовался в "Лукойле". 

Многие холдинги это используют: отдельно выделяется IT-структура как отдельная организация. Отношения с ней строятся по контрактному принципу. Понятно, что это организация, которая имеет преференции. Ее пытаются поставить в условия тендера – типа, "вы не единственный подрядчик, мы можем кого-то еще привлечь". Тем не менее, уже каким-то образом возникает некоторая формализация и контроль, учет обязательств. Что должна была сделать компания-подрядчик (пусть даже в структуре холдинга). Что должен был получить бизнес. Насколько это соответствует реальности.

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

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

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

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

Понятно, что это ненормальная ситуация ни в том, ни в другом случае. Они должны просто управляться. Сколько мы делаем вложений в IT и почему. 

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

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

Что здесь возникает.

Как сразу видно, возникают коммуникационные разрывы. Есть общение бизнесов со своими пользователями, со своими технологами, каждым из них. Но между ними общение строится более формально, более удаленно. Либо люди приезжают на территорию заказчика – они знакомятся, проводят интервью. Либо (в лучшем случае) технологи садятся на территорию заказчика, если есть такая возможность. Вступают в какие-то контакты с бизнесом заказчика и с пользователями.

Практика такова, что очень часто контакт между технологами, подрядчиком и пользователями очень плохой. Бизнес с бизнесом договорился про деньги, про сроки. Какие-то фичи, запросы бизнес-1 (заказчик) выдвинул. Подрядчик все эти фичи согласовал – договорились о неком контракте и начали работать. В ходе работы выясняется, что те или иные требования и ожидания пользователя вообще не были учтены, поняты. Это может очень дорого стоить обеим сторонам. 

Первая сторона говорит: "Смотрите, у нас тут такие-то были штуки, которые мы не учли. Давайте их переделаем". Подрядчик говорит: "Только за отдельные деньги". Заказчик говорит: "Нет! Зачем так делать? Мне кажется, переделки небольшие. Они находятся в рамках того вижена, который мы согласовали в договоре. Давайте сделаем их бесплатно". 

Вечная почва для конфликта в заказной разработке по поводу того, что должно быть сделано…

Есть попытка этот конфликт решать через детализацию ТЗ. ТЗ пишется на три страницы, ТЗ пишется на тридцать страниц, ТЗ пишется на триста страниц. Потом, в конце концов, все понимают, что потратили кучу времени, закопались в деталях, уже перестали понимать, что происходит. По ходу реализации программы выяснилось, что из ТЗ надо 70% выкинуть вообще нафиг.     

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

Они продают время, а потом выясняется, что "работу мы какую-то делали, система оказалась не нужной". Заказчик думает: "Ок. Я, наверное, больше не буду работать с этими ребятами, потому что систему, конечно, они сделали, но сделали совсем не то, что я хотел. Я лучше поищу каких-нибудь людей, которые лучше умеют работать с моими ожиданиями и с потребностями бизнеса". 

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

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

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

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

На последнее место я ставлю (ж)качество. (ж) Почему? Качество заказной разработки зачастую очень плохо осознается, оценивается, создается и потом проверяется. Все, что вы просили, мы сделали, но еще и управление ожиданием, потому что в ходе работы, как только что говорили на предыдущем докладе, постоянно мир меняется. Меняются ожидания потребителя, заказчика. 

Надо с этим уметь работать. Вовремя ловить либо давать человеку четко понять, что мы сейчас месяц делаем очередной релиз и там будет только вот это, это, это, а вот этого не будет, "потому что…". Либо пытаться ловить какие-то идеи заказчика. Новое понимание предлагать. Некие предстоящие релизы и проекты откладывать. 

Второй момент: контроль рентабельности. PM обычно должен отвечать за финансы проекта, если идет речь про заказную разработку, в которой у него есть какое-то количество людей в проекте. Это некая вторая составляющая его ключевых задач, как мне кажется. 

Типовые риски и рекомендации, что делать. 

Риски следующие: требования могут меняться неконтролируемо. Это головная боль всех PM. Есть голубая мечта в индустрии, которая существует уже, наверное, лет двадцать: давайте стараться всеми силами делать стабильные хорошие полные требования. 

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

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

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

Есть много проектов в индустрии, когда ПО сделано, формально сдано: оно так же, как покупной продукт, ставится на полку. Потому что люди не готовы его использовать, не готовы внедрять. Нет вообще никаких усилий, никакого понимания, как его внедрять, кроме как "коленом обязать" с 1-го числа начать работать в этой программе.  Очень часто такие вещи не взлетают. 

То, что я говорил. На диаграмме. Есть азы коммуникации между подрядчиком и пользователями. Из-за того, что в предоставленном проекте рассматривается ПО, а не бизнес-результат, то не учитывается полная стоимость внедрения. В планы внедрения не включаются деньги на создание системы, а не просто софта.

Есть рекомендации определенные по заказчику и подрядчику. Что делать. 

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

Если ваш подрядчик классно делает софт, это еще не значит, что этот софт у вас классно внедрится, взлетит и будет приносить вам пользу как компании. 

Подрядчику рекомендации немножко другие. Можно пытаться консалтинг, обучение про автоматизированные системы продавать, становясь не просто заказным разработчиком, а системным интегратором. Говорить: "Ребята, мы не просто ставим вам софт. Мы вам улучшаем бизнес. Мы знаем ваш бизнес и можем помочь его сделать лучше". 

Понятное дело, что для этого необходимо иметь определенный уровень зрелости компании. Быть не только технарями, но еще все-таки и консалтерами, разбираться в этом бизнесе. Такое получается не у всех, но к этому можно стремиться. Это всегда дает больший эффект, большие стратегические выгоды.

Второй вариант – это просто не напрягаться, не переживать, зная, что ты все равно делаешь ПО, которое может не взлететь. Ты понимаешь, что заказчик не готов к тому, чтобы это ПО было нормальным образом внедрено. 

Можно идти на такие условия чисто из-за корыстных бизнес-соображений, работая на потоке и говоря: "Ок, допустим, это внедряется в 30% проектов, а потом остается негативный осадок у заказчика. Тем не менее, мы в целом как компания продолжаем существовать и надеяться, что зрелость заказчиков в индустрии будет повышаться". 

Про контакт с пользователем. 

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

Следующий контекст – продуктовая разработка. Она чем-то напоминает предыдущую заказную, но тут есть существенные отличия. Здесь мы видим, что этих организаций уже множество. Есть множество потребителей и покупателей (вот эта связка БП). 

Это либо частные лица – владелец семьи, который финансирует покупку какого-нибудь "AutoСad для детей". Есть пользователь, который "AutoСad" использует – чему-то учится, рисует и приносит некоторую пользу для родителя. 

То же самое касается коммерческих компаний, где есть бюджет-холдеры и владельцы бюджетов, и выгодоприобретатели. Есть пользователи  (сотрудники компании), которые используют софт в работе. Какую-нибудь CRM систему. 

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

Обратите внимание. Здесь цель производства (производителя) совершенно другая относительно предыдущих контекстов. Если там говорилось, что мы хотим сделать ПО, мы хотим каким-то образом добиться улучшения бизнесовых показателей заказчика, то тут речь совершенно о другом. Мы хотим сделать продукт успешным на рынке. 

В каждом конкретном случае это могут быть разные вещи. Допустим, мы говорим, что выпускаем новый релиз, чтобы сохранить долю рынка. Тот же самый "Microsoft" может вполне делать это из таких соображений. Успех продукта на рынке означает, что новая операционная система через 2-3 года замещает предыдущую на 70%. Общее число инсталляций при этом должно не упасть, а вырасти на 20% в соответствии с ростом самого рынка. 

Это будет просто сохранение доли рынка. Это вполне себе некий вариант того самого успеха. 

Есть варианты стартапов, когда мы говорим, что у нас доля рынка нулевая. Мы хотим иметь к концу года долю рынка 10%. Каким-то образом оцениваем – выразимое в количестве инсталляций либо в идеале, конечно, в количестве прибыли, которую мы получаем.  

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

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

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

Он понимает, что продукты могут быть такими. Он говорит: "Ха! Странно – какого черта у вас на холодильнике нет того-то и того-то (сенсорная панель, что-то еще)". Он понимает, что если это существует в одной индустрии и это не очень дорого, доступно и так далее – он начинает такие ожидания иметь по поводу смежных индустрий. 

Время очень важно. Очень важно делать продукт определенного качества еще и в определенное время. Бывают разные форматы: какие-то продукты выпускаются в так называемом "голубом океане", когда нет вообще никакого рынка. Мы запускаем продукт, где нет конкурентов. Там можно играть со временем, пытаться ловить момент. 

На конкурентных рынках такое практически невозможно. Там необходимо очень четко в определенный момент выпускать продукт. Причем ловить всякие события типа отраслевых выставок, конференций и прочего. Например, есть сезонные эффекты типа новогодних распродаж. Есть эффекты "1-го сентября" и прочее. Все интернет-игроки в России, насколько я знаю, точно с этим работают. Запуски происходят либо весной, либо осенью.

Уравнение рентабельности достаточно редкое для всех этих контекстов. Оно специфическое. 

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

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

Здесь я пишу под вопросом: "Задача PM в создании успешного продукта". 

Мы говорили, что если целью является успех продукта на рынке, то, наверное, PM как раз отвечает за тот самый успех. Единственный вопрос здесь – PM ли отвечает за успех? Кто он такой, есть ли у него для этого права и полномочия. 

Тут еще возникает хороший вопрос "подковерный" по поводу трендов индустрии. Сейчас это мода и так далее. Есть классное уравнение рентабельности: там такая классная окупаемость и такие богатые люди с долями и прочими опционами. Почему мы все там не работаем? 

Тонкость в том, что шанс на успех у этих проектов гораздо меньше, чем у любых других проектов. Как раз сейчас (ж)Михаил(ж) показывал статистику по успешности проектов. Если там говорится, что в IT-индустрии в целом успешные проекты в одной трети случаев, то как раз в продуктовой разработке эта цифра не превышает одной десятой. Только 10% проектов реально добиваются успеха проекта на рынке. Но это еще очень хорошая оценка. 

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

Давайте посмотрим на риски продуктовой разработки и на рекомендации. Здесь риски совершенно другие. 

Ключевой риск – это то, что мы неправильно поняли рынок потребителя. 

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

Третий важный риск – это действия конкурентов. Вы понимаете, что вы на рынке не одни. В любой момент может выйти… Особенно актуально, я думаю, для интернета: какая-нибудь зарубежная компания, которая сделает продукт за меньшее время с лучшим качеством. Вы окажетесь в луже. 

Законодательство – тоже штука, которая для продуктовой разработки бывает актуальна. Может быть, вы знаете, что какое-то время все веб-сервисы, которые касались (неразборчиво) онлайн, были выведены из России за рубеж из-за того, что законодательство изменилось. 

Это может касаться любых систем. Например, Закон "О персональных данных" появляется. Необходимо будет все продукты к этому закону приводить. Это отдельная головная боль для разработчиков, которая может даже стоить им успеха на рынке. 

Какие рекомендации.

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

Есть такая тема, что этому руководителю необходимо давать полную ответственность за успех продукта как бизнеса в терминах P&L. Доходы и убытки – это все является его ответственностью. Есть два типовых варианта, которые есть сейчас на рынке, кто все-таки самый PM. На самом деле, ни черта не PM. Он называется product manager, потому что отвечает за продукт целиком, за его успех. Выступает внутренним заказчиком внутри компании. 

Второй вариант мне кажется более предпочтительным: когда его называют programm manager. Это традиция "Microsoft". Он курирует все проекты, которые необходимы, чтобы успех этого продукта на рынке состоялся. Если есть проект (неразборчиво) – допустим, исследовательский проект, проект по проектированию внешнего вида продукта, по продажам, по разработке, все одни должны быть скоординированы. Есть единственный человек, который за все это отвечает. В идеале он является непосредственным руководителем всех этих проектов. 

Базовая рекомендация для всех стартаперов: необходимо свой продукт регулярно проверять на потребителе. Какие бы вы идеи не придумали, как бы вам ни казалось, а практика бывает зачастую ошеломляющая. Выясняется, что те вещи, которые вы придумали, "вашей маме нравятся", а рынку не нравятся. 

Вот такие рекомендации. 

Остался последний контекст. Я думаю, он не очень актуален для интернет-компаний, с одной стороны. Но он нужен для некой полноты картины. Как раз мои коллеги очень активно занимаются рынком систем интеграции и внедрения. Занимаются тем, что не просто делают софт и веб-сервисы, а строят целую автоматизированную систему, которая позволяет бизнес поддерживать, развивать и так далее. 

Здесь возникает как минимум три контрагента, три отдельных бизнеса. Причем правый из них нас будет мало интересовать. Производитель обычно такой, что он говорит: "Я сделал некую Microsoft - CRM. Она внедряется в вашей компании-клиенте на 300 человек. Мы не заинтересованы никакие кастомизации делать относительно нашего продукта ради такого небольшого клиента. Если это будет Минфин России, тогда мы еще подумаем, чего доработать". 

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

В "Лаборатории Касперского" внедрялась система HTPPM. Возникал какой-нибудь маленький, но  мерзкий баг. Естественно, мы ждем его исправления от HP,  потому что сам подрядчик, внедренец не может его исправить по разным причинам.  

Что здесь происходит. 

Цели разные у всех трех сторон. Обычно производитель хочет просто продать лицензии, потому что он уже сделал продукт. Он просто хочет дальше по максимуму получать прибыль без всяких особых издержек. Чем больше лицензий продаст без работы, тем ему выгоднее. 

У подрядчика интерес, похожий на заказную разработку. Тоже есть некий контракт, просто в нем может быть оговорена не просто поставка ПО, а достижение неких бизнес-целей. Причем здесь тонкий момент заключается в том, что бизнес-целей подрядчик сам по себе никогда достигнуть не может. 

Это совместные усилия заказчика и подрядчика. Здесь как раз требуется высокий уровень синергии и доверия, чтобы они работали на бизнес-цели, а не просто: "ПО мы вам поставили. Оно стоит, работает, запускается. Чего вы от нас еще хотите?". Заказчик должен быть в идеале заинтересован в достижении неких бизнес-показателей через создаваемую систему.   

Атрибуты-драйверы другие. На первом месте стоит объем, качество. Цена и время вторичны. Тут нет жесткой упорядоченности. Есть два класса – более важный и менее важный. 

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

Как я понимаю, основная задача PM в этом контексте – интегрировать между собой разные работы, которые касаются процессов, регламентов, обучения людей, доработки софта, модификации инфраструктуры и так далее. Это некий challenge. 

Более точно, какие есть риски. Заказчик не захочет формулировать цели проекта в бизнес-единицах. Скажет: "Сделайте нам, поставьте такой-то софт, CRM-систему. Мы с помощью нее сможем что-то лучше делать". Что именно лучше делать – непонятно. Говорится фраза: "Повысим прозрачность". Можно очень долго работать (годами), тратить много денег на эту самую прозрачность, не понимая, достигли мы ее или нет. 

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

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

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

Вам спасибо за внимание! 

На вопросы я готов ответить сегодня. 

 

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Андрей Пантюхин

Андрей Пантюхин

В 2010–2012 построил Dream Industries в качестве первого CTO. Последние годы работает с ранними стартапами в России и за рубежом над продуктом и стратегией роста.

Андрей Пантюхин рассказывает об особенности работы с сообществами Open Source с применением коммерческого подхода.

Михаил Волович

Михаил Волович

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

Подробный рассказ о веб-фильтре Remparo, который позволяет ограничить доступ к нежелательному сетевому контенту.

Евгений Эльцин

Евгений Эльцин

Разработчик ПО в Google.

Евгений Эльцин (Google) рассказывает об исполнении нативного кода в браузере посредством использования Native Client.