Нет, считать давайте будем. Разве я призывал к отказу от планирования? Я лишь говорю, что в достаточно нестабильной (в первую очередь, экономически и административно) ситуации заниматься такими расчетами без определенной доли скепсиса не стоит. Ну и разумеется, нужно быть готовыми перекраивать стратегические планы «в связи с вновь возникшими обстоятельствами».
Просто рынок имеет смысл представлять не как бюджеты заказчиков, которые надо освоить и инсайды о тендерах, а как тренды в потребностях и эффективностью внедряемого
Ох, как это непросто… И дорого. Но правильно. Но поскольку дорого, далеко не у всех контор и конторок хватит ресурсов и смелости гнуть такую линию, даже несмотря на куда большие потенциальные барыши. Вот и живут «от зарплаты до зарплаты» (неплохо, в принципе, живут). Может, со временем будут больше внимания уделять стратегическому развитию.
Бизнес, может, и не проектный. Но отдельных проектов в нем — целые пачки. Это снова про перетекание одного в другое. Кстати, там же «в недрах», при наборе критической массы компетенций, иногда рождаются собственные продукты (решения).
«Сколько заработаем на несколько лет вперед» в наших реалиях увы, суть благие намерения по дележу шкуры хитрободрого медведя. Хотя, за неимением лучшего, и оно сгодится. Надо же от чего-то отталкиваться.
Из моих знакомых даже не топы предпочтут быть богатыми и здоровыми, нежели наоборот. Но довольствуются тем, что могут достать плюс занимаются реализацией амбиций.
И… эх… вот если бы работать только с теми, с кем приятно!
«Портфель проектов», «стратегия», управление по PMI… Это круто, это можно дорого продать. :)
А по жизни «портфель» — это куда контора смогла пролезть и где смогла урвать себе один или несколько кусков понажористее. Сейлы рыщут, аккаунты дергают связи, первые лица сажают печень в процессе установления доверительных отношений, а результат их общей работы валится на проектный офис (и других исполнителей) внезапно, поскольку до дня «Д» все было вилами по воде, а немногочисленные известные детали — «коммерческой тайной» (до тех пор, пока не договорились). Да и после дня «Д» некоторые моменты ей остаются (см., например, свежий «китайский» контракт Газпрома).
Пока мой опыт, включая работу в интеграторах из ТОП-..., показывает именно такую картину.
Я, например, на проекты смотрю по большей части с позиции ресурса. И для меня это бесконечная череда сменяющих друг друга проектов, с идентичными входами, выходами и характером работы, которую нужно проделать. Собственно, мне за это деньги и платят. Ну чем я не конвейер? А проекты в данном случае — преходящие мелочи.
А вот руководить менеджерам приходится не абстрактными категориями вроде «проекта» а конкретным, живым мной. Биологическим конвейером, то бишь. :)
Водоразделы есть, но есть и взаимный переход одного в другое. Поэтому жесткие противопоставления не особо радуют.
Терминология тут не при чем, я говорю про характер деятельности.
А терминология… Если надо, любую терминологию можно притянуть к реалиям за какое-нибудь хваткое место. Не на другой планете же ее выдумали.
Проект это временное предприятие по созданию уникального результата, а операции — это не уникальные повторющиеся действия. Не надо называть таски операциями. Задача менеджера проекта — управление проектом для достижения его целей, а чем управлять — дело вторичное (всем!).
Проектная и операционная деятельность — части одного целого. Помните круглый восточный знак слияния? Вот примерно так. Или, если угодно, в них есть что-то от фрактальной геометрии. Смотришь на общий рисунок — проект, однозначно. Всмотрелся в его участок — дык, процесс! Всмотрелся в участок процесса — снова проект! :)
Пример из жизни конторы-разработчика.
Уровень 1.
Процессы конторы рутинны: пресейл, контракт, работа, сдача, повторить. Чистой воды конвейер в несколько линий, которым надо управлять (чтобы не остаться в нужный момент без ресурсов, например).
Всматриваемся глубже.
Уровень 2.
Отдельные проекты конторы. Совершенно уникальные, со сроками, бюджетами, рисками. Классика.
Всматриваемся глубже.
Уровень 3.
Предположим, в конторе околоagile. В проекте — итерация за итерацией. Постановка — работа — контроль — повторить. Снова конвейер.
Всматриваемся глубже.
Уровень 4.
Внутри итерации результаты уникальны. Реализуются конкретные фичи, публикуются конкретные артефакты. Снова ресурсы и сроки. Проект!
Всматриваемся глубже.
Уровень 5.
Аналитик пишет постановку на итерацию. Встретился с заказчиком, написал что-то в спеку. Сбегал к архитектору, дописал. Созвонился с разработчиком — дописал. Получил доп. информацию еще из какого-то источника — внес. Повторить. Обратно, конвейер.
Всматриваемся глубже.
Уровень 6.
Отдельная встреча с заказчиком. Уникальное мероприятие со своими участниками (ресурсами), бюджетом (продолжительностью), сроками (датой). Уникальные результаты. Снова проект?
Всматриваемся глубже.
Уровень 7.
Поздоровались, расселись, давай допрашивать. Вопрос — ответ, следующий вопрос — еще ответ, повторить. Конвейер…
Всматриваемся глубже.
* * *
Мышление конечным результатом и сегодншними действиями и статусом проекта — это основной инструмент менеджера проектов. Если Ваш опыт говорит о менеджерах, которые не мыслят конечными результатами проекта — подсуньте тем менеджерам пмбок.
А если они мыслят не только конечными результатами проекта, способны заглянуть как в микро-, так и в макромир — выдайте им премию и повысьте. :)
Да, в управлении (особенно — в разработке) теоретические знания применять непросто. Из БоКа или откуда бы там ни было. Банально в силу его, управления, двойственной природы.
Полагаю, что не работал. По крайней мере, задачами, связанными с управленческими услугами «на продажу», не занимался.
Нельзя просто так взять, и применить PMBoK. :) (разве что под монитор подложить)
А вот строить управление своими проектами, применяя знания и рекомендации, вырванные из контекста PMBoK, неправильно интерпретированные и не туда приспособленные, можно запросто. Получится «что-то собственного приготовления».
То есть по факту один удачный раз и тот «по мелочи
Три. Два раза с результатом в виде реальных денег (пусть даже всего несколько сот тысяч), один — в виде явно обозначенной недоработки (упущенной прибыли) этого направления.
Количество «раз» не суть важно. Я утверждаю, что эту работу вполне можно вести с результатом, отличным от нуля даже в коммерции. А вести или нет — это каждый уполномоченный решает по ситуации.
Я подумаю над предложением «сфокусироваться». :)
Вообще, рецепт сокращения затрат на разработку документов по ГОСТ известен давно и применяется широко (судя по тому, что мне доводится читать в немалых количествах):
1. Берем действующего студента.
2. Даем ему ссылку на ГОСТ.
3. Даем ему файл с текстом договора/контракта.
4. Даем ему задание переписать текст контракта по шаблону ГОСТ за 2 дня.
(опционально) Если студент выглядит не сильно сообразительным, рекомендуем ему нагуглить примеров. Сообразительный догадается сам.
5. Расплачиваемся с ним дошираком или его денежным эквивалентом.
Готово. Быстро и недорого.
Если говорить чуть серьезнее, то объем методички по написанию ТЗ по ГОСТ 34 у меня составил 44 листа. Это явно не формат хабростатьи (кроме того, права на нее принадлежат организации, которая за нее заплатила). И цель методички — помочь в написании качественных документов, а не сократить расходы на их подготовку.
В любом случае — благодарю за высказанное мнение и его обоснование.
Да, по большей части госы. И специфика там своя. Документации пишется много, спрашивается строго, применяется потом мало.
Там можно управлять документированием на уровне интересов отдельных руководителей подразделений. Которым это действительно нужно (чтобы обучить сотрудников, решить какие-то параллельные задачи, прикрыть внезапно возникшую потребность или, как в примере, отстоять «честь семьи»). Не суть важно. Важно, что даже в такой ситуации что-то сделать можно. А поскольку госы — это фиксированная стоимость, торг обычно идет не за деньги, а за остальной функционал. Или «услуги» (прим: «Вы на предварительной приемке закрываете глаза на эти ляпы, а мы взамен делаем вот этот внезапно понадобившийся документ»)
«Но в коммерческой разработке ни разу не было, чтобы удалось продать документацию.»
Было два раза. По мелочи, правда. И один раз два директора и один менеджер проекта на совещании получили взбучку от коммерческого заказчика за халатность по этой теме. По существу взбучку. Документы наваяли, но не те и не так.
«В отличие от b2c рынка, где потребность можно создать за счет эмоций и сиюминутности, на b2b рынке для создания потребности надо вложить очень много денег, и то не факт что получится.»
В целом да, согласен — чаще всего это именно так. Но иногда бывает достаточно объяснить преимущества ответственному лицу. И если шанс есть — почему бы им не воспользоваться?
«Кроме того под эту потребность надо будет экономическое основание писать, на слово обычно не верят.»
В технико-коммерческом предложении таким обоснованиям самое место. Я даже привел в статье часть из того, что можно использовать.
«даже если их удастся продать, то не более чем 10% от общей суммы проекта.»
В последние несколько лет мне редко доводится участвовать в проектах с бюджетом менее 100 млн. рублей. 10% этой суммы — это немало. :)
* * *
Кроме того, «продать» можно не только за деньги. Продать можно в качестве замещения другой проектной работы, которую делать не хочется или не можется. («Не, давайте без этой фичи. А взамен мы вот такую инструкцию напишем!»)
Я просто не понимаю, зачем Вы это пишете. И пишете в публичной области. Это кому-то интересно?
Хотите меня убедить, что в английском слово «sale» отличается от «seller»? Охотно верю.
Хотите меня убедить, что слово «сейл» не употребляется в коммерческих компаниях (в т.ч. в ИТ-отрасли) достаточно крупных, чтобы иметь свой штат продавцов? Что его не понимают, считают невежливым или даже грубым (как, например, «продажный отдел»)? Нет, не убедили. Тут я предпочту верить своим глазам и ушам, извините.
Хотите меня убедить, что не следует употреблять разговорные выражения в тексте статьи? Возможно, но это прошу оставить на мое усмотрение и направить педагогические усилия в более конструктивное русло.
Ну, раз уж вынесли — нужно было выносить и тот текст, на который был дан этот ответ. Заодно показали бы мне «просьбу исправить англонизм «сейлы»». Возможно, я ее не заметил.
Могу назвать навскидку 3-4 интегратора из топ-20, в которых этот термин употребляется каждый день (в чем я имел и имею возможность убедиться лично). Общая численность персонала в них — более 5 тыс. человек. Считаю даже такую аудиторию достаточной, чтобы назвать термин «устоявшимся».
Это не выходя за пределы отрасли ИТ.
Сожалею, что незнание авторитетов дает Вам основания для обвинений кого-либо во вранье.
Нет, считать давайте будем. Разве я призывал к отказу от планирования? Я лишь говорю, что в достаточно нестабильной (в первую очередь, экономически и административно) ситуации заниматься такими расчетами без определенной доли скепсиса не стоит. Ну и разумеется, нужно быть готовыми перекраивать стратегические планы «в связи с вновь возникшими обстоятельствами».
Ох, как это непросто… И дорого. Но правильно. Но поскольку дорого, далеко не у всех контор и конторок хватит ресурсов и смелости гнуть такую линию, даже несмотря на куда большие потенциальные барыши. Вот и живут «от зарплаты до зарплаты» (неплохо, в принципе, живут). Может, со временем будут больше внимания уделять стратегическому развитию.
«Сколько заработаем на несколько лет вперед» в наших реалиях увы, суть благие намерения по дележу шкуры хитрободрого медведя. Хотя, за неимением лучшего, и оно сгодится. Надо же от чего-то отталкиваться.
Из моих знакомых даже не топы предпочтут быть богатыми и здоровыми, нежели наоборот. Но довольствуются тем, что могут достать плюс занимаются реализацией амбиций.
И… эх… вот если бы работать только с теми, с кем приятно!
А по жизни «портфель» — это куда контора смогла пролезть и где смогла урвать себе один или несколько кусков понажористее. Сейлы рыщут, аккаунты дергают связи, первые лица сажают печень в процессе установления доверительных отношений, а результат их общей работы валится на проектный офис (и других исполнителей) внезапно, поскольку до дня «Д» все было вилами по воде, а немногочисленные известные детали — «коммерческой тайной» (до тех пор, пока не договорились). Да и после дня «Д» некоторые моменты ей остаются (см., например, свежий «китайский» контракт Газпрома).
Пока мой опыт, включая работу в интеграторах из ТОП-..., показывает именно такую картину.
Я, например, на проекты смотрю по большей части с позиции ресурса. И для меня это бесконечная череда сменяющих друг друга проектов, с идентичными входами, выходами и характером работы, которую нужно проделать. Собственно, мне за это деньги и платят. Ну чем я не конвейер? А проекты в данном случае — преходящие мелочи.
А вот руководить менеджерам приходится не абстрактными категориями вроде «проекта» а конкретным, живым мной. Биологическим конвейером, то бишь. :)
Водоразделы есть, но есть и взаимный переход одного в другое. Поэтому жесткие противопоставления не особо радуют.
Терминология тут не при чем, я говорю про характер деятельности.
А терминология… Если надо, любую терминологию можно притянуть к реалиям за какое-нибудь хваткое место. Не на другой планете же ее выдумали.
Проектная и операционная деятельность — части одного целого. Помните круглый восточный знак слияния? Вот примерно так. Или, если угодно, в них есть что-то от фрактальной геометрии. Смотришь на общий рисунок — проект, однозначно. Всмотрелся в его участок — дык, процесс! Всмотрелся в участок процесса — снова проект! :)
Пример из жизни конторы-разработчика.
Уровень 1.
Процессы конторы рутинны: пресейл, контракт, работа, сдача, повторить. Чистой воды конвейер в несколько линий, которым надо управлять (чтобы не остаться в нужный момент без ресурсов, например).
Всматриваемся глубже.
Уровень 2.
Отдельные проекты конторы. Совершенно уникальные, со сроками, бюджетами, рисками. Классика.
Всматриваемся глубже.
Уровень 3.
Предположим, в конторе околоagile. В проекте — итерация за итерацией. Постановка — работа — контроль — повторить. Снова конвейер.
Всматриваемся глубже.
Уровень 4.
Внутри итерации результаты уникальны. Реализуются конкретные фичи, публикуются конкретные артефакты. Снова ресурсы и сроки. Проект!
Всматриваемся глубже.
Уровень 5.
Аналитик пишет постановку на итерацию. Встретился с заказчиком, написал что-то в спеку. Сбегал к архитектору, дописал. Созвонился с разработчиком — дописал. Получил доп. информацию еще из какого-то источника — внес. Повторить. Обратно, конвейер.
Всматриваемся глубже.
Уровень 6.
Отдельная встреча с заказчиком. Уникальное мероприятие со своими участниками (ресурсами), бюджетом (продолжительностью), сроками (датой). Уникальные результаты. Снова проект?
Всматриваемся глубже.
Уровень 7.
Поздоровались, расселись, давай допрашивать. Вопрос — ответ, следующий вопрос — еще ответ, повторить. Конвейер…
Всматриваемся глубже.
* * *
А если они мыслят не только конечными результатами проекта, способны заглянуть как в микро-, так и в макромир — выдайте им премию и повысьте. :)
Ребят, а в каком-нибудь более распространенном формате у вас нет? В чем-то из MS офиса, например? (да хоть .png)
Полагаю, что не работал. По крайней мере, задачами, связанными с управленческими услугами «на продажу», не занимался.
Нельзя просто так взять, и применить PMBoK. :) (разве что под монитор подложить)
А вот строить управление своими проектами, применяя знания и рекомендации, вырванные из контекста PMBoK, неправильно интерпретированные и не туда приспособленные, можно запросто. Получится «что-то собственного приготовления».
Так что лидер — он по-прежнему лидер.
Три. Два раза с результатом в виде реальных денег (пусть даже всего несколько сот тысяч), один — в виде явно обозначенной недоработки (упущенной прибыли) этого направления.
Количество «раз» не суть важно. Я утверждаю, что эту работу вполне можно вести с результатом, отличным от нуля даже в коммерции. А вести или нет — это каждый уполномоченный решает по ситуации.
Я подумаю над предложением «сфокусироваться». :)
Вообще, рецепт сокращения затрат на разработку документов по ГОСТ известен давно и применяется широко (судя по тому, что мне доводится читать в немалых количествах):
1. Берем действующего студента.
2. Даем ему ссылку на ГОСТ.
3. Даем ему файл с текстом договора/контракта.
4. Даем ему задание переписать текст контракта по шаблону ГОСТ за 2 дня.
(опционально) Если студент выглядит не сильно сообразительным, рекомендуем ему нагуглить примеров. Сообразительный догадается сам.
5. Расплачиваемся с ним дошираком или его денежным эквивалентом.
Готово. Быстро и недорого.
Если говорить чуть серьезнее, то объем методички по написанию ТЗ по ГОСТ 34 у меня составил 44 листа. Это явно не формат хабростатьи (кроме того, права на нее принадлежат организации, которая за нее заплатила). И цель методички — помочь в написании качественных документов, а не сократить расходы на их подготовку.
В любом случае — благодарю за высказанное мнение и его обоснование.
Там можно управлять документированием на уровне интересов отдельных руководителей подразделений. Которым это действительно нужно (чтобы обучить сотрудников, решить какие-то параллельные задачи, прикрыть внезапно возникшую потребность или, как в примере, отстоять «честь семьи»). Не суть важно. Важно, что даже в такой ситуации что-то сделать можно. А поскольку госы — это фиксированная стоимость, торг обычно идет не за деньги, а за остальной функционал. Или «услуги» (прим: «Вы на предварительной приемке закрываете глаза на эти ляпы, а мы взамен делаем вот этот внезапно понадобившийся документ»)
«Но в коммерческой разработке ни разу не было, чтобы удалось продать документацию.»
Было два раза. По мелочи, правда. И один раз два директора и один менеджер проекта на совещании получили взбучку от коммерческого заказчика за халатность по этой теме. По существу взбучку. Документы наваяли, но не те и не так.
В целом да, согласен — чаще всего это именно так. Но иногда бывает достаточно объяснить преимущества ответственному лицу. И если шанс есть — почему бы им не воспользоваться?
«Кроме того под эту потребность надо будет экономическое основание писать, на слово обычно не верят.»
В технико-коммерческом предложении таким обоснованиям самое место. Я даже привел в статье часть из того, что можно использовать.
«даже если их удастся продать, то не более чем 10% от общей суммы проекта.»
В последние несколько лет мне редко доводится участвовать в проектах с бюджетом менее 100 млн. рублей. 10% этой суммы — это немало. :)
* * *
Кроме того, «продать» можно не только за деньги. Продать можно в качестве замещения другой проектной работы, которую делать не хочется или не можется. («Не, давайте без этой фичи. А взамен мы вот такую инструкцию напишем!»)
Хотите меня убедить, что в английском слово «sale» отличается от «seller»? Охотно верю.
Хотите меня убедить, что слово «сейл» не употребляется в коммерческих компаниях (в т.ч. в ИТ-отрасли) достаточно крупных, чтобы иметь свой штат продавцов? Что его не понимают, считают невежливым или даже грубым (как, например, «продажный отдел»)? Нет, не убедили. Тут я предпочту верить своим глазам и ушам, извините.
Хотите меня убедить, что не следует употреблять разговорные выражения в тексте статьи? Возможно, но это прошу оставить на мое усмотрение и направить педагогические усилия в более конструктивное русло.
Могу назвать навскидку 3-4 интегратора из топ-20, в которых этот термин употребляется каждый день (в чем я имел и имею возможность убедиться лично). Общая численность персонала в них — более 5 тыс. человек. Считаю даже такую аудиторию достаточной, чтобы назвать термин «устоявшимся».
Это не выходя за пределы отрасли ИТ.
Сожалею, что незнание авторитетов дает Вам основания для обвинений кого-либо во вранье.
Если потребности нет, то:
а) надо объяснить, зачем нужна документация, и создать потребность.
б) не надо заморачиваться с документацией.
В каждом отдельном случае решение принимать ответственным за это сотрудникам.