Баланс сторон на внутренних проектах. Почему внутренние проекты - вечные?

27.12.22

Управление проектом

В данной статье я хочу поделиться с вами своими мыслями и набитыми шишками. Я расскажу о психологии управления внутренних проектов, сложностях, с которыми вы обязательно столкнетесь. Правильно было бы в начале ограничить рамки своего рассказа. Как видно из названия рассказывать я буду про внутренние проекты. Так как сам я занимаюсь только проектами по 1С - то это тоже принимаем к учету. Будем говорить про бизнес ERP системы и только про крупных Заказчиков.

Для начала я хочу пару слов сказать о методологиях управлений проектами. Какая методология чаще используется на внутренних проектах:

  1. Внутренние проекты больше заточены на то, чтобы поставлять ценность как можно быстрее.
  2. Что касается обновления требований – требования на внутренних проектах зачастую очень гибкие, то есть меняются довольно часто. Тут сразу ТОП менеджменту бизнеса захочется сказать: «А зачем мы вообще свой штат разработчиков набрали – конечно же, чтобы быть более гибким».

Исходя из своего опыта и тех рамок, которые я задал в начале – то есть (1С, крупный бизнес, ERP системы) могу сказать, что крупный бизнес никогда не согласится на НИОКР в части Бизнес системы. Крупному бизнесу нужна четкость. Но так как это внутренний проект, под внутренним проектом бизнес видит инструмент, который позволит быстро поставлять ценность и корректировать требования. Вывод: в 90% случаев – это не Agile – это водопадная модель, но с большим количеством блоков и прототипов. Так выглядит попытка бизнеса усидеть сразу на двух стульях, получая одновременно и гибкость, и прогнозируемость. Как это в итоге будет реализовано - большой вопрос, все зависит от компетенции руководства. Могу сказать от себя только то, что видел на своем веку предиктивные проекты, которые пользовались терминами SCRUMа, и наоборот, проекты, которые были на бумаге предиктивными, а по факту команда полностью плясала под дудку бизнеса, выполняя все новые и новые хотелки.

 

Почему бизнес выбирает именно внутренний проект?

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

Какие есть отличия у проекта внешнего и внутреннего:

  • Отношение к ресурсам. Ресурс — это работник компании.
    • Во внутренних проектах к нему относятся как к постоянному сотруднику. Ресурс, уходя из проекта, уходит из компании.
    • На внешнем – это эксперты (так их зачастую представляют) из другой компании. То есть повлиять на команду можно только в рамках зафиксированной в уставе проекте процедуры. Поменять ресурс - исполнителя - не так-то просто, придется строчить жалобы, ссориться и так далее.
  • Психология управления на внутреннем проекте. Она больше похожа на управление отделом. Это и есть ИТ отдел.
    • Отдел встроен в компанию и подчиняется общим правилам компании
    • ИТ отдел занимается не только внедрением ERP систем - у него есть много других функций, главная из которых - чтобы все работало.
  • Заточенность под большое количество инкрементов и большой уровень изменяемости требований.
  • Мотивация. Зарплата и ИТ бюджет компании, против выручки от проекта. На внутреннем проекте нет отношений "клиент - заказчик".
    • На внешнем проекте Исполнитель заточен на то, чтобы закрыть требования, пройти ПСИ, пройти ОПЭ, все что сверх ФТТ – доработать за отдельные деньги через ЗНИ – получить деньги и уйти. Цель - получить прибыль, то есть затратить ресурсов меньше, чем стоимость в договоре.
    • На внутреннем проекте – Исполнитель является частью ИТ отдела. Цель ИТ отдела – это поддержание ИТ инфраструктуры.

В первом случает есть нацеленность на результат, во втором на процесс. В первом КПИ заточен на выручке, во втором люди получают зарплату.

 

Баланс сторон.

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

 

 

Давайте рассмотрим, как каждый из этих видов сотрудников реагирует на внутренний проект:

  • Топы. Всегда в любом внедрении (внешне или внутренне) инициатива изначально по внедрению идет сверху. Решение принимается всегда сверху. Любое внедрение – это увеличение ИТ бюджета – соответственно закос делается даже намного раньше – при согласовании годового бюджета компании.

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

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

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

  • Руководители. В центре находятся кто? прослойка руководителей отделов/департаментов/подразделений. Здесь – в этом месте идет соприкосновение интересов.

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

Какими мотивами руководствуется руководитель:

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

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

Что я хочу показать данным рисунком?

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

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

 

Какие проблемы бывают на внутренних проектах?

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

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

Что может быть причиной срыва сроков проекта:

Банальные, всем известные причины не будем разбирать, все мы их знаем:

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

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

Проблема №1. Не проведена предварительная организационная работа с Руководителями

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

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

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

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

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

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

Проблема №2. Низкий уровень влияния РП внутри компании

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

На этом теряется время, которое уже не вернуть.

Проблема №3. Саботаж внедрения

Что входит в состав этого страшного слова.

Долгое согласование решений. Тянется время

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

Отказ от приемки работ без объяснения причин

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

Постоянное добавление новых требований

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

Отказ подстраивать процесс под систему

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

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

 

Причины быть против автоматизации:

Сейчас мы будем говорить про прослойку Исполнителей и Руководителей. 

Причина №1. Бардак

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

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

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

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

Но в 90% случаев и в тех рамках, что мы описали -  автоматизируется то, что устаканено. Четкие и ясные БП.

Причина №2. Потенциальное изменение

Любое изменение потенциально является риском

Причина №3. Потенциальное уменьшение отдела

Когда тебе говорят, что мы внедрим систему и вместо 9 человек будет 3 – это не очень вдохновит на содействие

Причина №4. Потеря контроля, потеря статуса уникального ресурса.

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

Причина №5. Страхи

Как на это все реагирует Исполнитель. Например: финдир, знающий, как настраивать типовые отчёты, работать с фильтрами, сможет сам себе формировать оперативные отчеты за 5 секунд, а не просить младших это делать (то есть не надо писать письмо, не надо следить за корректностью, открыл отчет, а если нужен другой разрез, выбрал другую настройку или фильтр, или сам под себя настроил то что самому нужно видеть). Время работы сокращается. Рутинные функции убираются и люди освобождаются, и это освобождение людей от их функций их пугает.

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

 

Мотивация ИТ-шника в внутренних проектах

В отдельную проблему я вывел – мотивацию сотрудников. Рассмотрим ее поглубже.

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

Исполнитель проекта является частью ИТ отдела. Цель ИТ отдела какая – это поддержание ИТ инфраструктуры. Здесь больше заточенность на процесс, а не результат.

На внешнем проекте Исполнитель заточен на то, чтобы закрыть требования, пройти ПСИ, пройти ОПЭ, все, что сверх ФТТ – доработать за отдельные деньги через ЗНИ – получить деньги и уйти. Цель - получить прибыль, затратить ресурсов меньше, чем стоимость в договоре.

Какие проблемы могут быть с мотивацией

Остаться на работе, а не выполнить работу как можно скорее и уволиться – это такое некое подсознательная мысль, она есть у всех на внутреннем проекте

ЗП на внутреннем выше, чем у франчей, ресурсу выгодней сидеть на больших Зарплатах.

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

Как можно решить эту проблему:

Способ я вижу только один – сформировать KPI, заточенный под выполнение вех. В моей практике и в практике людей, которых я опрашивал по внутренним проектам, данные KPI были только у РП или их вообще не было. KPI надо распространять и на исполнителей проекта – аналитиков, разработчиков.

НЕ надо формировать KPI, заточенный на количество отработанных заявок от бизнеса, тогда это подстегнёт людей не реализовывать проект, а выполнять как можно больше заявок. Так будет создаваться иллюзия работы, но не результат.

ИТ бюджет на год

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

Например: Есть у бизнеса ИТ отдел и ИТ бюджет. И есть KPI по вехам. РПшник на внутреннем проекте будет более заинтересован в том, чтобы растянуть проект как можно дальше, раздуть проблему (из мухи слона), увеличить ИТ отдел, перевыполнять план и осваивать ИТ бюджет. Это прямая мотивация.

А не: нанять побольше людей, выполнить проект за 2 года, а не за пять и уволить потом 70% персонала, оставив только сервисное обслуживание. Покажите мне ситуацию, где это происходило? 

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

Как решить проблему

Большой уровень вовлечения ТОПов в процесс, сторонняя экспертиза и аудит. Я вижу выходы только такие.

 

На что должен быть заточен внутренний проект

Какая основная цель бизнеса? – прибыль. Проект должен быть прибыльным.

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

Эффективность

Главная цель автоматизации – это увеличение производительности труда. То есть увеличение показателя "Результат"/"Работа" (стандартная формула рентабельности)

Есть идея внедрить ИС автоматизации бюджетирования в отдел (20 человек), который полностью все делает вручную. Могут быть следующие результаты:

  • Провели проект и потом наняли 2 человека на поддержку и уволили 10 финансистов.
  • Провели проект и потом наняли на сопровождении 7-8 дорогих ИТшников, уволили 2 финансистов.

В первом случае хорошо, во втором плохо.

 

Инвестиционный проект

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

Удовлетворённость конечного пользователя

Если надо следовать трендам – это обусловлено средой в которой находится компания.

 

Эффективность проекта – что это? Как измерить и должен ли проект вообще быть эффективным?

Как измерить эффективность внутреннего проекта. Для этого есть множество методик, формул, расчетов. Не обязательно их знать, но важно понимать основные базовые принципы. Более того, не обязательно на реальном проекте вообще все это в числах рассчитывать. Есть базовые понятия эффективности – их достаточно. Прибыль должна быть больше затрат.

Что есть прибыль и что есть затраты?

  • Затраты –ясное дело цена внедрения, есть понятие стоимость владения, сюда добавляются еще затраты по железу
  • Прибыль – экономия, то есть уволили человека или сократили объем работ человека так, чтобы он мог заниматься чем-то другим,

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

Как правило, следить надо за тем, чтобы он не стал АРХИубыточным. Почти все внутренние проекты убыточные – если оценивать по стоимости.  Главное то, как мы относимся к внедрению.

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

Рассмотрим пример. Есть задача по доработке. Прилетела от пользователя, пользователь просит сделать "хорошо", но это нарушает типовой процесс ЕРП (все мы понимаем, что будет, если раздолбать ЕРП). Даже если мы видим, что пользователь на самом деле выполняет работу, которую можно автоматизировать, но доработка затрагивает пару других блоков, то это выйдет в большое количество человеко-часов. А экономия времени при работе даст нас экономию 5-10 минут.

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

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

  • Стоит ли эту задачу делать или нет. В первом подходе мы ее заблокируем
  • Во втором случае сделаем, потратим ресурсы. Целесообразность этих трат – большой вопрос.

Минус многих внутренних проектов в том, что никто не оценивает такие доработки на соответствие первоначальному плану и запросы пользователя выходят на первый план, так как KPI ИТшников зависит от того, примет ли работу заказчик. А он, будучи в состоянии решать да или нет, понимая, что есть власть, пользуется этим дабы достигнуть своих целей цели.

 

Главная мысль

Любой внутренний проект – это не только задача для ИТшников – это также задача для ТОПов. Это управленческая задача.

Позиция: мы внедрим систему в бардак и бардак исчезнет – не работает.

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

Порядок действия такой:

  1. ТОПы должны понимать, что они должны тратить свой админ ресурс на контроль и продвижение своей идеи по внедрению систем.
  2. Подготовить прослойку Руководителей в том, что бизнес процессы будут изменены и РУКоводители должны быть за автоматизацию. Они должны быть в курсе и готовы к изменениям, подготовительная работа должна быть проведена, гайки закручены где надо.
  3. Ставя систему на бардак – получаем автоматизированный бардак. В начале наводим порядок в процессах, а потом внедряем продукты.
  4. ИТ отдел должен быть нацелен на выполнение проекта в срок, то есть должен быть KPI по срокам во внутреннем ИТ-отделе не только у РПшника.
  5. Если ИТ-бюджет раздувается – проводить экспертизу и аудит деятельности.

 

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

Внутренний проект Управление проектом Эффективность Топ менеджмент

См. также

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного РП и тимлида. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все особенности работы руководителей проектов.

02.05.2024    2969    0    biimmap    39    

38

Канбан и поставка ценности Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

При разработке 1С:Бухгалтерии 8 используются унифицированные процессы обработки задач, построенные на методике Kanban. О том, как выглядит доска задач, в чем пишут код команды – в конфигураторе или в EDT, и что делается для повышения качества и понятности кода самого многопользовательского проекта фирмы «1С», пойдет речь в статье.

26.04.2024    4089    0    mrXoxot    5    

29

Канбан и поставка ценности Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Применение Agile в отделе разработки 1С:Бухгалтерии не сразу оправдало возложенные на него ожидания. Но только благодаря гибким методикам удалось стабилизировать выпуск релизов и перестроить разработку так, чтобы она всегда начиналась с анализа задачи и с общения с пользователями. Расскажем об квинтэссенции опыта разработки самого многопользовательского проекта фирмы «1С».

23.04.2024    3435    0    user1853337    8    

29

Кейсы проектов Руководитель проекта Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    3307    0    1СERP    21    

31

Кейсы проектов Программист Бизнес-аналитик Пользователь Руководитель проекта Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    15046    0    ASchekachev    37    

55

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    6163    0    stnslv    5    

25

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    5206    0    andironenko    3    

32

Компетенции и навыки РП Бизнес-аналитик Руководитель проекта Бесплатно (free)

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

12.01.2023    5783    0    MariaTemchina    28    

22
Оставьте свое сообщение