В рамках организационной модели действительно можно выделить работы подрядчика как «подпроект». Но это необязательно.
Если зависимости сильные, что возможно лучше будет работы подрядчика интегрировать в общий план проекта заказчика и рассматривать как «пакеты работ» (work packages) или даже прямо как отдельные «задачи».
То есть тут нет универсального рецепта по организации взаимодействия и контроля.
Подряд организационно можно интегрировать в проект разными способами.
При этом подряд — это отдельная и явная единица управления. Менеджер «проекта» на стороне подрядчика является прежде всего менеджером подряда.
Например, он должен оценивать и учитывать в смете не только затраты на выполнение работ проектного характера, но и затраты на выполнение всех обязательств, взятых в рамках подряда (например, гарантийные обязательства и т.п.). Он должен понимать договор конкретно его подряда, и знать права и обязанности подрядчика в рамках законодательства.
1. Я не про документы, а про сущности предметной области финансов, которые представлены этими документами. Почитал статью на Википедии про инвестиционный проект. По переводам статьи и ссылкам можно предположить, что термин «инвестиционный проект» — это недавнее российское изобретение для пояснения начинающим. Термин больше из финансового менеджмента. У коллег-финансистов своя предметная область и немного другие вещи в центре внимания и центре терминологии. Многие из настоящих проектов действительно подпадают под определение термина «инвестиционный проект». Однако ни одно из понятий не включает другое, так как под инвестиционный проект, судя по статье, также попадают инвестиции в денежные активы.
2. Есть подозрение, что вы совсем неточно используете термин "неграмотность".
Проект — организационное понятие, подряд — юридическое.
Совершенно верно. «Подряд» — это понятие делового оборота, закреплённое в юридической терминологии. Поэтому трактовать его можно достаточно узко и точно. В отличии, от понятия «проект», за неточное использование которого никому ничего не будет, кроме споров с коллегами.
Если проект рассчитывается и оплачивается как услуги, от этого проект не перестает быть проектом.
Терминология делового оборота, я считаю, должна быть приоритетнее организационной. Это НЕ проект рассчитывается и оплачивается как услуга или подряд. Это элементы и методы проектного управления могут быть использованы для расчёта сметы подряда или услуги, а также использованы для выполнения обязательств, взятых в рамках подряда или услуги.
Я собственно статью в том числе писал и для менеджеров «проектов» внутри подрядчиков, чтобы они всегда понимали, что они прежде всего делают подряд и помогают заказчику выполнить его проект, а не просто делают свой «проект».
Если результат проекта нужен не исполнителю, а заказчику (спонсору), то от этого проект не перестает быть проектом.
Нисколько не спорю, вот цитата из моей статьи:
Так как разработка ПО – дело дорогое и рискованное, то компания-подрядчик может завести у себя внутри суррогатный проект. Но все должны чётко понимать, что такой проект ни в коем случае не замена нормальному, полноценному проекту на стороне компании-получателя выгод.
Заказчику может не быть никакого дела, как подряд выполняется, в форме проекта, или вообще как угодно.
Это одна из мыслей, которую я и хотел донести. Заказчику абсолютно по фигу на ваш «проект», главное, чтобы вы выполняли ваш подряд.
Надо смотреть на это с высоты птичьего полёта. Заказчик, несмотря на то, что с вашей стороны он играет роль в ваших процессах, со своей стороны он в них не участвует, а просто пользуется вашими продуктами (или сервисами) через согласованные интерфейсы. Для него ресурс — это всегда ваш продукт. Ваш процесс, как ресурс он не распознаёт.
Я всё-таки рекомендую использовать такой расклад, так как он сочетается с предметными областями ITIL и TOGAF, выверенными годами и большим количеством людей, а не ломает их.
1. Увеличение стоимости компании — это про balance sheet, а не про cash flow. Надеюсь, вы понимаете разницу между тем, что описывается документами "cash flow statement", "balance sheet" и "income (или profit and loss) statement" и не надо писать статью про то, что не все деньги одинаково деньги.
2. Вы можете, пожалуйста, привести пример, когда «когда делают вместо кого-то, подряжаются» и при этом «создают полезное для себя». И вам не кажется, что подряд тоже подпадает под определение «когда временно делают некоторый результат»?
Процитирую сам себя, первый абзац:
Предметные области услуг и управления в ИТ достаточно сложны и нетривиальны. Эта сложность происходит из-за неосязаемости большинства предметов в этих областях. Несмотря на это, люди почему-то используют очень простые подходы к классификации предметов. Буквально по нескольким атрибутам.
Скажу честно, вы можете жить с подобным подходом, тратя время на решение заложенных в нём конфликтов, недопонимания и неверных ожиданий. Мы тоже тратили, и я всего лишь на хочу, чтобы кто-то другой ещё тратил. И плюс этот семантический хаос автоматизировать end-to-end нормально не сможете, если будете переходить на более крупный масштаб деятельности.
Ну вот серии наших статей на пятых частях и пересеклись :-)
Я как раз в своей серии статей и пытаюсь устранить путаницу, которая происходит из-за подобных упрощений.
Нет универсальной системы координат, всегда нужно понимать, какая компания/организационная единица в центре системы координат, когда упоминаются ПэРы.
Вы в третьей части пишете:
Продукты — то, что компания выпускает, будь это Сервис или Физический продукт; Проекты — проект это деятельность которая конечна во времени и всегда направлена на создание продукта; Процессы — это то, что мы делаем ежедневно для поддержания компании и наших продуктов в жизнеспособном состоянии;
В принципе нормальные не мудрёные определения.
Но в реальности есть продукты, проекты и процессы вашей компании, и есть продукты, проекты и процессы заказчика. (Более того, цепочки реальных коммерческих взаимоотношений в B2B настолько сложны, что бывает необходимо ещё и распознавать ПэРы ваших субподрядчиков и ПэРы конечного потребителя).
На самом деле, всё, что вы делаете не для себя, это в вашей терминологии должно называться продуктами вашей компании. И продукты вашей компании будут использоваться в продуктах, проектах и процессах заказчика.
Соответственно, то распределение, которое вы привели для обозначенных условных групп, это распределение продуктов вашей компании в ПэРах заказчика.
В общем от меня есть пожелание всегда приписывать название организации к ПэРам. Тогда у людей картина будет складываться гораздо чётче.
В остальном, очень хорошее начинание. Поддерживаю.
я всё-таки настаиваю на предложенной терминологии: «проект» и «подряд», а не «проект» и «проект».
Хотя всем снаружи вашей компании всё равно, как вы называете, то, чем занимаетесь, но у людей реальная каша в головах, когда проектом называют и проект и подряд.
Сразу неконкретными становятся понятия «менеджер проекта», «требования проекта», «бюджет проекта», «сроки проекта» и т. п.
В итоге начинают путаться и заказчик (особенно не очень зрелый), менеджер подряда и команда подрядчика. Люди начинают договариваться не понятно о чём.
В общении с заказчиком имеет смысл разговаривать на его языке, исходя из его центра системы координат.
Не согласен с введением понятия «инвестиционный проект». Настоящий проект — это не про увеличение свободных денег, а про увеличение стоимости компании (если с точки зрения финансистов).
Проект — это способ реализации организационного изменения. А подряд — это способ реализации объёма работ.
Подрядчик в рамках подряда ничего полезного для себя не создаёт, поэтому рассмотрение подряда как отдельного проекта, имеет мало смысла. Это действительно костыльно получается. Подряд в B2B всегда имеет смысл рассматривать как часть проекта и со стороны заказчика и со стороны подрядчика.
Возможно это трудности перевода, но с моей точки зрения тут есть небольшая дырка, которую изобретатели велосипедов будут трактовать как индульгенцию на использование их велосипедов.
Должно быть так:
«Я не говорю, что вы не должны использовать готовый код.» => "Вы должны использовать готовый код"
«Использование отличных и проверенных библиотек, баги которых исправлены, а преимущества подтверждены несколькими годами тестирований, практически всегда очень хорошееединственно правильное решение»
— особенно с учётом того, для кого написана статья.
Насчёт «Изобретайте велосипед». Всё-таки проблему в идеале решать комбинацией предыдущих двух советов: «Читайте код, написанный другими» и «Работайте с теми, кто умнее вас», а именно включиться в открытый проект и начать активно добавлять туда функционал, а то и переделывать.
Можно и поизобретать велосипеды для практики и самовыражения, но ни в коем случае не применять этот велосипед в работе при наличии отлаженных рабочих аналогов. Надо разделять хобби и работу. Вам и бизнес и последующие разработчики скажут «огромное спасибо».
therubyracer под windows не работает, насколько я помню из своего опыта работы с рельсами в марте этого года. Да и смысла нет в этой замене, даже для Linux. Для работы рельсов с помощью nodejs npm не требовался.
Кстати, говоря про прямые ответы, ответа на вопрос «проводите ли вы опрос об удовлетворенности» не было.
То, что клиентов мало — не значит, что они удовлетворены.
Об этом надо спрашивать клиентов напрямую.
Дело не всегда только в достаточных мощностях.
Это круто, если это всегда было очевидно для вас. Для меня не всё из этого было сразу очевидно, честно признаюсь. Было бы откровенное капитанство, не тратил бы время на перевод. Начинающие руководители, особенно бывшие инженеры, частенько недопонимают некоторые из этих свойств. Плюс в статье есть ссылки, где тема разбирается подробнее.
Как у нас в компании дела обстоят, реально надо спрашивать наших клиентов. Мы, естественно, стараемся реализовать все 4 свойства по-максимуму, но нам всё ещё есть, что улучшать, так как мы не всегда получаем оценку удовлетворенности 10 из 10.
А вы проводите опрос об удовлетворенности услугами RingCloud среди ваших клиентов?
Просто перечислять риски особого смысла нет. Важно закрепить ответственность за них. Причем лучше всего на качественно другом уровне, как я написал в комментарии:
Наиболее надёжный способ закрепления области ответственности — это описать её в договоре. В например посредством таких инструментов, как:
описание услуги,
описание гарантий качества в виде уровней обслуживания,
описание ценовой модели, определяющей случаи, в которых плата может быть больше, в каких — меньше, а в каких — не будет изменяться.
Этот качественно другой уровень адресует риски обычно уже категориями.
Возьмём для примера риск того, что инженер (поставщика услуги) поддержки серверов Windows заказчика заболеет и в это время сервер «упадёт».
В таблице ниже я привёл упрощённые формулировки для контракта для двух разных по уровню зрелости и границе распределения рисков, чтобы было понятнее. Выделил курсивом идентичный текст.
На самом деле формулировки будут ещё сильнее различаться, потому что границы не одним риском отличатся будут, но для иллюстрации я различия свёл к минимуму.
Вообще это будет темой отдельной статьи.
Задача определения ответственности разделяется на три:
задача эффективного распределения областей ответственности
задача однозначно понятного описания области ответственности
задача закрепления области ответственности
Первая задача грубо решается так: кто может управлять риском в наибольшей степени, тому и стоит отдать ответственность за него.
Про инструменты для описания ответственности буду писать в соответствующих статьях.
Наиболее надёжный способ закрепления области ответственности — это описать её в договоре. В например посредством таких инструментов, как:
описание услуги,
описание гарантий качества в виде уровней обслуживания,
описание ценовой модели, определяющей случаи, в которых плата может быть больше, в каких — меньше, а в каких — не будет изменяться.
Дай знать, пожалуйста, если я неправильно понял твой вопрос.
Непостоянство качества — товары также обладают этим свойством, для чего есть гарантийный сервис. К тому же мы, как поставщики услуг стремимся к воспроизводимому качеству и автоматическому предоставлению = одинаковому качеству.
Непостоянством качества можно ограниченно управлять, сокращая то. что может изменяться. Для настоящих ИТ-услуг, то есть полностью автоматических, непостоянство действительно сведено к минимуму.
Вовлечение — смотря что имеется в виду, заказчик точно всегда вовлечен в процесс оплаты услуги и контроля качества, а вот в процесс потребления может быть и не вовлечен — например услуга по покупке репетитора для ребенка, можно найти и другие примеры — например перепродажа услуги для конечного клиента — заказчик вовлечен в процесс перепродажи и приемки/ сдачи, а в предоставление не вовлечен, это делает конечный клиент…
Вовлечение — это то, что потребитель может повысить ценность услуги для себя, высказывая пожелания в процессе получения услуги.
Неотделимость: сделав автоматическую услугу ( облачный сервис) и продав ее другому поставщику — я нарушаю первые 3 определения услуги
Смотря, что ты называешь облачным сервисом. Если настроенное программно-аппаратное решение, то это ещё не услуга, а активы поставщика в полной боевой готовности. То есть то же, что и парикмахерская с парикмахерами. То, что ты написал, может подразумевать два разных варианта:
Передача права собственности на свои активы другому поставщику так, что он сможет оказывать услугу без тебя. Но это не оказание услуги и тут потребитель не нужен. Активы поставщика как раз очень хорошо отделены от потребителей, что и порождает несохраняемость.
Покупка услуги другим поставщиком, чтобы добавить ценность и перепродать дальше. В данном случае, потребителем выступает тот самый другой поставщик. Так что неотделимость в этом случае никуда не девается.
Несохраняемость — как известно мы стремимся сделать из услуги коробку, чтобы ее было легче продавать, те описав и задокументировав услугу мы можем ее сохранить для других клиентов. Потом, сделав сервисцентр ты одну и ту же услугу предоставляешь разным клиентам с одинаковым качеством по своим стандартам.
То, что ты описал — это повышение потенциала/капитализации активов поставщика. Несохраняемость — это про безвозвратно потерянную коммерческую возможность. Если ты имел в виду, повышение потенциала активов посредством простаивающих мощностей, то это частный случай перенаправления простаивающих мощностей на другого потребителя (себя). Как в примере с парикмахером, обслуживающим другого клиента. Только за бесплатно. Это, на самом деле, всего лишь незначительная компенсация потерь.
Или услуга предоставления электричества: провайдер запасает услугу в дизельном топливе и батареях, чтобы в случае сбоя предоставить клиенту.
Это особый случай организации поставки физической энергии по сервисной модели. Но это лучше рассматривать как исключение, которое подчёркивает правило. Да и там возможности по запасанию крайне ограничены. Дизельное топливо и дизельный генератор — это не запасание, а дополнительные капитальные и операционные затраты. Неиспользуемое электричество в дизельное топливо же не превращается.
Если зависимости сильные, что возможно лучше будет работы подрядчика интегрировать в общий план проекта заказчика и рассматривать как «пакеты работ» (work packages) или даже прямо как отдельные «задачи».
То есть тут нет универсального рецепта по организации взаимодействия и контроля.
Подряд организационно можно интегрировать в проект разными способами.
При этом подряд — это отдельная и явная единица управления. Менеджер «проекта» на стороне подрядчика является прежде всего менеджером подряда.
Например, он должен оценивать и учитывать в смете не только затраты на выполнение работ проектного характера, но и затраты на выполнение всех обязательств, взятых в рамках подряда (например, гарантийные обязательства и т.п.). Он должен понимать договор конкретно его подряда, и знать права и обязанности подрядчика в рамках законодательства.
2. Есть подозрение, что вы совсем неточно используете термин "неграмотность".
Совершенно верно. «Подряд» — это понятие делового оборота, закреплённое в юридической терминологии. Поэтому трактовать его можно достаточно узко и точно. В отличии, от понятия «проект», за неточное использование которого никому ничего не будет, кроме споров с коллегами.
Терминология делового оборота, я считаю, должна быть приоритетнее организационной. Это НЕ проект рассчитывается и оплачивается как услуга или подряд. Это элементы и методы проектного управления могут быть использованы для расчёта сметы подряда или услуги, а также использованы для выполнения обязательств, взятых в рамках подряда или услуги.
Я собственно статью в том числе писал и для менеджеров «проектов» внутри подрядчиков, чтобы они всегда понимали, что они прежде всего делают подряд и помогают заказчику выполнить его проект, а не просто делают свой «проект».
Нисколько не спорю, вот цитата из моей статьи:
Это одна из мыслей, которую я и хотел донести. Заказчику абсолютно по фигу на ваш «проект», главное, чтобы вы выполняли ваш подряд.
Я всё-таки рекомендую использовать такой расклад, так как он сочетается с предметными областями ITIL и TOGAF, выверенными годами и большим количеством людей, а не ломает их.
2. Вы можете, пожалуйста, привести пример, когда «когда делают вместо кого-то, подряжаются» и при этом «создают полезное для себя». И вам не кажется, что подряд тоже подпадает под определение «когда временно делают некоторый результат»?
Процитирую сам себя, первый абзац: Скажу честно, вы можете жить с подобным подходом, тратя время на решение заложенных в нём конфликтов, недопонимания и неверных ожиданий. Мы тоже тратили, и я всего лишь на хочу, чтобы кто-то другой ещё тратил. И плюс этот семантический хаос автоматизировать end-to-end нормально не сможете, если будете переходить на более крупный масштаб деятельности.
Я как раз в своей серии статей и пытаюсь устранить путаницу, которая происходит из-за подобных упрощений.
Нет универсальной системы координат, всегда нужно понимать, какая компания/организационная единица в центре системы координат, когда упоминаются ПэРы.
Вы в третьей части пишете:
В принципе нормальные не мудрёные определения.
Но в реальности есть продукты, проекты и процессы вашей компании, и есть продукты, проекты и процессы заказчика. (Более того, цепочки реальных коммерческих взаимоотношений в B2B настолько сложны, что бывает необходимо ещё и распознавать ПэРы ваших субподрядчиков и ПэРы конечного потребителя).
На самом деле, всё, что вы делаете не для себя, это в вашей терминологии должно называться продуктами вашей компании. И продукты вашей компании будут использоваться в продуктах, проектах и процессах заказчика.
Соответственно, то распределение, которое вы привели для обозначенных условных групп, это распределение продуктов вашей компании в ПэРах заказчика.
В общем от меня есть пожелание всегда приписывать название организации к ПэРам. Тогда у людей картина будет складываться гораздо чётче.
В остальном, очень хорошее начинание. Поддерживаю.
Хотя всем снаружи вашей компании всё равно, как вы называете, то, чем занимаетесь, но у людей реальная каша в головах, когда проектом называют и проект и подряд.
Сразу неконкретными становятся понятия «менеджер проекта», «требования проекта», «бюджет проекта», «сроки проекта» и т. п.
В итоге начинают путаться и заказчик (особенно не очень зрелый), менеджер подряда и команда подрядчика. Люди начинают договариваться не понятно о чём.
В общении с заказчиком имеет смысл разговаривать на его языке, исходя из его центра системы координат.
Не согласен с введением понятия «инвестиционный проект». Настоящий проект — это не про увеличение свободных денег, а про увеличение стоимости компании (если с точки зрения финансистов).
Проект — это способ реализации организационного изменения. А подряд — это способ реализации объёма работ.
Подрядчик в рамках подряда ничего полезного для себя не создаёт, поэтому рассмотрение подряда как отдельного проекта, имеет мало смысла. Это действительно костыльно получается. Подряд в B2B всегда имеет смысл рассматривать как часть проекта и со стороны заказчика и со стороны подрядчика.
Должно быть так:
— особенно с учётом того, для кого написана статья.
Можно и поизобретать велосипеды для практики и самовыражения, но ни в коем случае не применять этот велосипед в работе при наличии отлаженных рабочих аналогов. Надо разделять хобби и работу. Вам и бизнес и последующие разработчики скажут «огромное спасибо».
То, что клиентов мало — не значит, что они удовлетворены.
Об этом надо спрашивать клиентов напрямую.
Дело не всегда только в достаточных мощностях.
Спасибо за пожелание!
И вам удачи!
Как у нас в компании дела обстоят, реально надо спрашивать наших клиентов. Мы, естественно, стараемся реализовать все 4 свойства по-максимуму, но нам всё ещё есть, что улучшать, так как мы не всегда получаем оценку удовлетворенности 10 из 10.
А вы проводите опрос об удовлетворенности услугами RingCloud среди ваших клиентов?
Этот качественно другой уровень адресует риски обычно уже категориями.
Возьмём для примера риск того, что инженер (поставщика услуги) поддержки серверов Windows заказчика заболеет и в это время сервер «упадёт».
В таблице ниже я привёл упрощённые формулировки для контракта для двух разных по уровню зрелости и границе распределения рисков, чтобы было понятнее. Выделил курсивом идентичный текст.
На самом деле формулировки будут ещё сильнее различаться, потому что границы не одним риском отличатся будут, но для иллюстрации я различия свёл к минимуму.
Задача определения ответственности разделяется на три:
Первая задача грубо решается так: кто может управлять риском в наибольшей степени, тому и стоит отдать ответственность за него.
Про инструменты для описания ответственности буду писать в соответствующих статьях.
Наиболее надёжный способ закрепления области ответственности — это описать её в договоре. В например посредством таких инструментов, как:
- описание услуги,
- описание гарантий качества в виде уровней обслуживания,
- описание ценовой модели, определяющей случаи, в которых плата может быть больше, в каких — меньше, а в каких — не будет изменяться.
Дай знать, пожалуйста, если я неправильно понял твой вопрос.Вовлечение — это то, что потребитель может повысить ценность услуги для себя, высказывая пожелания в процессе получения услуги.