Оценка и планирование проекта

Публикация № 318158

Методология - Управление проектом

Немного статистики о проектах. Примерно 30% ИТ-проектов проваливаются. И только 16% ИТ-проектов укладываются в сроки и в бюджет. Чтобы было понятно, кто мы такие, расскажу пару слов о своей компании. Я представляю проектный офис «Савеловский» компании «Первый БИТ». Мы, собственно, занимаемся тем, что делаем проекты. И я расскажу о том, как мы делаем свои проекты.

Этапы проекта

  

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

Этап «Начало проекта» - здесь мы говорим про некую инициацию проекта, когда появляется заказчик, который говорит нам: «Я хочу чудо».

  • После того, как заказчик это чудо захотел, он хочет понять, сколько это чудо стоит. Соответственно, мы переходим на этап «Оценка проекта».
  • Потом на этапе «Планирование проекта» у нас появляются какие-то сроки.
  • Дальше - этап «Выполнение» проекта.
  • И потом - этап «Завершение проекта».

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

 

Сегодня мы будем обсуждать два первых этапа – этапы «Оценка проекта» и этап «Планирование проекта». Я их специально выделил на слайде.

Этап оценки проекта

Итак, как мы делаем оценку проекта?

 

Я хотел бы начать с цитаты Уинстона Черчилля, который как-то сказал: «Любой умный человек может составить план победы в войне, если он не отвечает за выполнение этого плана».

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

  • Первая оценка: приходит заказчик и спрашивает, сколько это будет стоить.
    Мы ему говорим – «пять логанов». Заказчик говорит – «нет, дорого».
    Тогда мы ему говорим – «ну, тогда два». Заказчик говорит – «два? Нормально».
    Это – продажная оценка.
  • И вторая оценка – это уже более-менее реальная оценка. Когда мы начинаем двигаться дальше к исполнению этого проекта и понимаем, что все-таки два логана – это было, наверное, маловато, что все-таки проект стоит не меньше четырех логанов.

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

 

Исходя из своего опыта, я выделяю три способа проведения оценки:

  • Аналогия
  • Декомпозиция
  • Метрика

Давайте каждый из способов отдельно обсудим.

Первый способ оценки – аналогия.

Вроде все понятно: у нас был какой-то проект, который мы делали два года назад. К нам приходит заказчик и спрашивает: «Сколько это будет стоить?»

Мы с этим вопросом идем к нашему человеку, который делал этот предыдущий проект. Он чешет голову, вспоминает и говорит: мы делали этот проект за два логана, потратили на него 2000 часов.

Плюсы такой оценки понятны – это быстрая оценка.

Какие могут возникнуть проблемы, если вы будете оценивать свои проекты таким способом?

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

Аналогия – это интуитивно понятный процесс, здесь ничего сложного нет.

Следующий способ оценки – декомпозиция

Собственно, декомпозиция является стандартом де-факто всех оценок. 90% всех оценок делаются с помощью декомпозиции.

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

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

Какие у нас здесь возникают ключевые проблемы?

  • Когда мы делим проект на задачи, то может потеряться интеграционная составляющая по взаимодействию этих частей между собой. И если у вас нет человека, который мог бы в голове представить этот проект, определить взаимосвязь выделенных блоков между собой, тогда вам нужно будет делать где-нибудь внизу приписку: «Интеграционная составляющая проекта – 25%»(25% – это в лучшем случае, иногда 50%). Ведь если мы не можем правильно оценить интеграционные затраты, то, соответственно, у нас возникают дополнительные риски, которые нужно закрывать. Я думаю, что на интеграционный момент всегда нужно закладывать не меньше 10-25%.
  • У декомпозиции есть еще одна проблема – это трудоемкость ее проведения. Есть более-менее простые проекты, которые достаточно быстро можно оценить, декомпозировать. Но встречаются настолько сложные проекты, что только сам процесс их оценки будет составлять 40-50-80 и более часов. Это уже достаточно серьезная работа, которая требует выделения отдельных ресурсов.

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

Третий способ оценки - метрика

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

Что такое метрика как способ оценки? Мы выделяем некое количественное выражение проекта и по этой метрике оцениваем отдельную единицу трудозатрат на отдельную единицу этой метрики. Соответственно, дальше мы получаем эту количественную оценку и просто умножаем трудозатраты одной единицы на общее количество метрики. В результате получаем оценку трудозатрат по всему проекту.

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

Какая проблема здесь есть?

  • Самая главная проблема в том, что далеко не все проекты поддаются метрике.

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

Теперь такой вопрос – как мы делаем оценку на практике?

Мы должны делать не одну, а две оценки.

  • Мы должны сделать оценку с участием сотрудников заказчика

И мы должны сделать оценку только нашими силами.

Что это означает?

 

Здесь указана декомпозиция по задачам. Есть первая задача и вторая. У нас есть две колонки с трудозатратами – колонка №1 и колонка №2.

  • В колонке №1 мы указываем трудоемкость этой задачи с минимальным нашим привлечением,
  • В колонке №2 мы указываем общую трудоемкость этой задачи.

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

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

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

Двойная оценка трудоемкости – это один из самых удачных примеров конкретизации объема планируемых затрат.

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

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

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

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

  • Первый вопрос – как понять адекватность оценки?
    • Адекватность понять можно в первую очередь следующим образом – нужно в эту оценку поверить. Адекватность – это когда вы начинаете понимать, что проект будет вот таким, и он будет происходить вот в такой последовательности, и на вот такой объем будут требоваться вот такие трудозатраты.
    • Второй способ проверки адекватности – это попросить кого-нибудь сделать повторную оценку той же работы. Примерно треть оценок, которые нам приходится выполнять, связаны с тем, что наши заказчики просят нас оценить какой-то проект. Мы понимаем, что это повторная оценка (для того, чтобы с кем-то сравниться), но мы все равно ее делаем для того, чтобы удовлетворить потребности клиента.
      Здесь сразу возникает следующий вопрос – если у вас была одна оценка (где было два логана) и появилась другая (где десять логанов), то, как понять, какая из этих оценок более адекватна?
      По большому счету, единственный способ найти ответ на этот вопрос – это понять, что написано в этой оценке и просто в те цифры, которые вам предъявляют. Если вы не верите, значит, эта оценка неадекватна для вас. Других способов оценки адекватности нет.
    • Второй вопрос – как подрядчик включает в оценку свои риски?
      Очень просто. Он просто пишет в договоре отдельным пунктом риски проекта 10% или 25%. Конечно, очень часто бывает ситуация, когда такой отдельной строчки в договоре нет, и просто все трудозатраты по всем задачам умножаются на 0.25. Но мы так стараемся не делать. Мы всегда отдельно обговариваем, что есть определенные риски, которые мы не можем смоделировать.
    • Третий вопрос – когда возникают риски?
      Риски возникают на разных проектах по разным причинам. Они могут возникать на согласовании, на трудоемкости ввода, на других этапах. Естественно, все эти риски мы стараемся каким-то образом озвучить, зафиксировать, что здесь мы видим такие риски, и мы в них закладываемся. Это – некий НЗ, который мы для себя фиксируем «на всякий случай», стараясь в этот НЗ не залезать. И обосновываем для заказчика, что если мы в этот НЗ залезаем, то это происходит по вот таким причинам.
    • И последний вопрос – что самое важное в оценке?
      Я об этом уже сказал – в нее нужно поверить. Других вариантов просто нет. Если вы верите в эту оценку – это нормальная оценка, правильная. Если не верите, значит, что-то в ней не так.

Этап планирования проекта

Переходим к следующему этапу – этап планирования. Как мы планируем проекты?

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

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

Какие вообще варианты планирования проекта у нас есть? Их тоже три.

  • Первый вариант планирования – это планирование от старта проекта. Когда у нас есть перечень работ, указанный в оценке, и мы просто раскладываем эти работы на календарный график. А дальше уже от этого откладываем какие-то сроки выполнения каждого из этапов. Это разумный, часто встречающийся подход.
  • Следующий вариант планирования – это планирование от даты X. Здесь тот же самый принцип, что и в первом варианте, только здесь мы планируем от конца, когда у нас есть некая конечная дата – например, дата запуска проекта (дата старта новой базы) – 1 января 2014 года. Соответственно, мы раскладываем перечень наших работ от этой даты назад.

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

Как не надо планировать?

Очень часто на старте проекта заказчики и исполнители пытаются спланировать проект следующим образом:

  • Все сразу
  • Детально
  • И более чем на 6 месяцев.

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

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

Зачем пытаться спланировать сразу все? Сроки и так более-менее понятны, мы их планируем изначально по большим этапам.

Что надо учитывать при планировании?

  • При планировании нужно обязательно учитывать интенсивность обучения. Разные люди обучаются по-разному – кому-то требуется 2 дня на то, чтобы обучиться, а кому-то требуется 2 недели. Это достаточно существенная разница. Поэтому, когда мы приходим к этапу обучения, внедрения, когда уже идет запуск в опытную эксплуатацию – разная скорость обучения может сыграть свою роль. Это надо учитывать и понимать, что группы обучения очень разнородны.
  • Тестирование. На этапе перевода в опытную, промышленную эксплуатацию тестированием занимается заказчик. И при планировании нужно закладываться на то, что этот этап может быть очень длительным, так как тестирование обычно выполняется пользователями заказчика в свободное от работы время. А поскольку у них 100% рабочего времени занимает выполнение их первоочередных рабочих обязанностей, то этап тестирования, как правило, затягивается надолго. И если по вашим оценкам трудозатраты на тестирование должны составить 8 часов, можно спокойно увеличивать их в 4 раза.
    Я сейчас говорю не про тестирование со стороны разработчика, потому что в любом случае работу принимает заказчик. И вот эта приемка работ – она, как правило, может занимать очень длительное время. На это нужно закладываться при планировании.
  • Тестирование и загрузка ресурсов Заказчика – это связанные между собой вещи, то есть очень часто пользователи заказчика заняты так, что на проект у них времени не остается, поэтому одни и те же трудозатраты раскладываются на гораздо более длительный срок. Растягиваются и могут растягиваться очень сильно. Это тоже нужно учитывать и при планировании закладывать на это дополнительное время (по длительности задачи).
  • Объемы обрабатываемых данных. Здесь речь идет о том, что базы могут быть очень большими. Например, необходимо понимать, что перенос данных может проходить со сбоями. Поэтому если мы закладываем на него 40 часов, то на самом деле из-за большого объема данных эта длительность может быть гораздо больше просто из-за того, что могут быть сбои, перезагрузки и т.д. На эти все вещи нужно закладываться минимум раза в два.

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

По этапу планирования проекта я тоже набросал очевидный список вопросов:

  • Нужно ли планировать ресурсы с самого начала?
    Крупными мазками, наверное, надо. В любом случае надо понимать, кто будет делать задачу – разработчик или консультант. Но указывать при этом конкретные персоналии мне кажется, не стоит.
    Когда мы планируем на период больше, чем 2 недели, поименно указывать, кто будет выполнять ту или иную задачу – бессмысленно. Через 2 недели смысла в вашем планировании особого не будет. Человек может заболеть, может пропасть, может уйти в отпуск. Но мы можем заложить конкретные ресурсы на проект в целом, просто чтобы на каком-то длительном этапе понимать, что этот человек нам может понадобиться. При этом мы не говорим, что он нам понадобится на этой конкретной задаче. Он просто проходит у нас, как некий ресурс на этом проекте. А на какой конкретно задаче мы его используем, мы в рамках долгосрочного планирования закладывать не должны.
    Вообще реальное распределение ресурсов по задачам должно происходить в ходе реализации, диспетчеризации задач в рамках одно-двух недельных этапов планирования. Планировать сразу, говорить, что через 3 месяца Вася Иванов будет делать такую-то задачу – это «вилами по воде писано» или «пальцем в потолок».
    Например, у меня была ситуация – на проекте был определенный круг бизнес-пользователей заказчика, которым я должен быть демонстрировать свою работу. Соответственно, когда я раскидал задачи, связанные с ними, по месяцу, я не зарезервировал их время на работу на нашем проекте. И в результате получилось, что я пришел на первое согласование, а половины людей нет: у одних – отпуска, у других – другие задачи и т.д. Пришлось перепланировать.
    В итоге получается, что у нас, технических руководителей проектов, есть задача в целом, есть ресурсы на проекте и наша цель – сохранить эту команду проекта на все время подготовки проекта. Все. По большому счету, не важно, куда человек с проекта может уйти – в отпуск или не в отпуск, на другой проект или куда-то еще. Поэтому руководителю проекта приходится, в том числе, планировать отпуска тех сотрудников, которые входят в эту команду, и для этого мы обычно просто договариваемся с человеком: пока идет проект, в отпуска не уходим – конечно, если у нас проект обозримой длительности по времени (три-пять-шесть месяцев).
  • Какой этап самый длительный?
    Непростой вопрос. В разных проектах по-разному. Я считаю, что самый длительный, самый сложный этап – это этап внедрения, когда мы что-то накодировали и теперь начинаем это все внедрять – переносить остатки, обучать пользователей. Вот этот этап перехода от некоего концепта к опытной промышленной эксплуатации , пожалуй, занимает большую часть времени, чем другие этапы проекта.
  • И последний вопрос – можно ли не планировать?
    Можно. Но не нужно. Если перефразировать Эйзенхауэра – ни одна битва в истории человечества не прошла так, как ее задумывал полководец. Но без планирования победы не бывает.
    Планирование необходимо. В любом случае мы должны планировать проект в целом по этапам, по задачам. И что гораздо правильнее - именно контролировать ход исполнения проекта, контролировать попадание в разработанный план и работать с изменениями. Но это уже относится не к этапам оценки и планирования, а больше к этапу исполнения проекта.

Заключение

Очень часто проекты находятся в состоянии «перманентного планирования». Но надо уже когда-то начинать воевать. Потому что там что-то планируют, потом перепланируют, создают первую оценку, потом – вторую, третью, потом опять что-то планируют…

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

 *******

Статья написана на основе доклада, прочитанного на Конференции IE 2013 Revolution (7-8 ноября 2013 года). Также она опубликована в журнале Инфостарта № 3  

Приглашаем вас на новую конференцию INFOSTART EVENT 2017 COMMUNITY.

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
2. AlexWhite 193 02.01.15 12:56 Сейчас в теме
Какие-то крупные проекты по аналогии оценить невозможно

По-моему, наоборот, чем крупнее проект, тем легче воспользоваться аналогией для оценки. Например, когда-то реализовали проект в объеме 10000 часов. Вероятность того, что аналогичный проект уложится в этот объем в будущем гораздо выше, чем если сделали проект за 500 часов и думаем, что аналогичный уложится в эти же 500 часов.
3. raiml 704 10.01.15 00:31 Сейчас в теме
Статья откровенно плохая.И по форме и по содержанию. Для кого вы это писали? Уровень сочинения для средней школы.


5. Nikola23 589 17.01.15 00:17 Сейчас в теме
(3) raiml, а конкретику укажете? Где ошибки у автора? В чем его мнение расходится с Вашим. Или это сообщение добавлено, что бы заработать SM?
4. Князь 74 14.01.15 07:08 Сейчас в теме
Статья хороша. Весьма близка к реалиям. С удовольствием подметил, что интуитивно применяемые на практике методы оценки (в основном, декомпозиция и дальнейшая оценка по аналогии) , оказывается, имеют обширное теоретическое обоснование.
Разумеется, каждый примеряет статью на свой личный жизненный опыт, так что вполне возможны критические придирки по форме и содержанию статьи от лиц, малознакомых с методами оценки трудоёмкости проектов.
6. Jonny_F 06.03.15 13:12 Сейчас в теме
Статья хорошая. Немного размыто. Но по сути – верная. Жаль что- порядок оценки раскрыт не полностью, верее очень кратко.
Оставьте свое сообщение

См. также

Стратегия выживания в корпоративных войнах Промо

Управление проектом Бесплатно (free)

Айтишникам сложно строить карьеру управленца. И все потому, что в их «техническое ДНК» не заложено умение справляться с окружающими их интригами. Однако, поскольку это навык, это можно исправить, считает ИТ-директор в ПАО «Светлана». На конференции Infostart Event 2018 он поделился с коллегами, что и как надо делать, чтобы не погрязнуть в корпоративных интригах и сделать так, чтобы они не мешали выполнению основной работы.

16.09.2019    10893    GSoft    16    

9 советов, как уговорить девушку. Точнее, как уговорить Заказчика работать по Agile, когда он этого не хочет

Управление проектом Бесплатно (free)

Как знает большинство старожилов Инфостарта, я люблю устраивать разного рода онлайн-обсуждения. И эта статья написана как раз по итогам такого рода вебинара-дискуссии. 

16.02.2021    2887    MariaTemchina    39    

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

Управление проектом Управление командой Бесплатно (free)

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

10.02.2021    3845    andironenko    13    

Статья Компетенции РП по версии PMI и здравому смыслу. Часть 2-ая

Управление проектом Бесплатно (free)

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

09.12.2020    1671    MariaTemchina    3    

Ошибки управленцев: как топ-менеджеров убивает перфекционизм Промо

Управление проектом Бесплатно (free)

В преддверии онлайн-конференции «Гнев и слезы руководителя» мы решили заранее познакомить нашу аудиторию со спикерами, причем сделать это через видео-истории. Начнем с видео-приглашения от Миланы Джиджоевой и ее виденья диджитализации рекрутинга в России.

24.01.2019    10247    user809424    11    

Что почитать про Agile для чайников?

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Продолжаю рубрику “Письма в редакцию”. Ко мне иногда обращаются с вопросом - вот, я, мол, совсем не представляю, что такое Agile…

03.12.2020    3341    MariaTemchina    9    

Компетенции руководителя проекта: по версии PMI и здравому смыслу. Часть 1-ая.

Управление проектом Бесплатно (free)

Об компетенции руководителя проекта сломано немало копий (хорошо, если не об самих руководителей).  В этой статье хочу оставить свои пять копеек, отталкиваясь от тех компетенций, которые институт PMI® - законодатель моды мирового проектного управления - озвучил в качестве требований к сертификации PMP® со 2-ого января 2021 года.

18.11.2020    3220    MariaTemchina    8    

Как стать исполнителем в проекте от Инфостарта

Управление командой Управление проектом Бесплатно (free)

Инфостарт в поисках специалистов, которые готовы взяться за реализацию интересных проектов. Как подать заявку и стать исполнителем, с кем согласна сотрудничать компания и на каких условиях, рассказал руководитель проектов корпоративного отдела Инфостарта Александр Блинов.

11.09.2020    3202    alexandr.blinov    17    

Проблемы внедрения 1С:ERP на крупном предприятии Промо

Управление проектом Бесплатно (free)

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом реальных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию очередную статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

29.06.2017    35437    1СERP    79    

Давайте спасем древесных осьминогов или 12 советов для начинающих РП от опытных товарищей

Управление проектом Бесплатно (free)

Ниже я попыталась собрать житейские советы от опытных руководителей проектов 1С и выпускников курсов по управлению ИТ-проектами на Инфостарте с моими комментариями. 

04.09.2020    3509    MariaTemchina    23    

Что делать, если с поддержкой 1С всё горит или несколько слов про ITSM…

Управление услугами и сервисом Управление бизнес-процессами (BPM) Управление прочее Управление проектом Бесплатно (free)

Проекты - это, конечно, важно, с завершением проекта внедрения, жизнь прикладного решения, на самом деле, только начинается. И самое интересное еще только впереди… Не случайно в Agile все чаще говорят о “гибком управлении продуктом”, а вовсе не только “проектом”.

20.08.2020    3225    MariaTemchina    4    

Управление в стиле Догвилль

О жизни Управление проектом Бесплатно (free)

Как и почему жизнь на работе становится всё хуже. Или всё лучше.

26.06.2020    4716    1c-intelligence    17    

История одного неуспешного проекта Промо

Управление проектом Бесплатно (free)

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом неуспешных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию первую статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

09.06.2017    31717    1СERP    175    

Есть ли жизнь после внедрения, или упрощаем работу в сопровождении

Управление проектом Бесплатно (free)

Из-за отсутствия грамотных правил разработки на этапе внедрения сильно усложняется работа по поддержке и развитию типовых доработанных конфигураций. О некоторых правилах и подходах в разработке, которые помогут специалистам сопровождать внедренное решение, на конференции Infostart Event 2019 Inception рассказал разработчик компании «Инвестиционная группа Абсолют» Алексей Степаненко.

08.06.2020    5447    stepan96    12    

Добрый великан

Управление проектом Бесплатно (free)

Руководители проектов определяют наше настоящее, каким оно будет?! Ответ прост - таким, каким и сам РП.

25.05.2020    5878    sapervodichka    1    

Почему Scrum не работает в проектах 1С

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Более точная формулировка заголовка, пожалуй будет такой -  Почему Scrum в чистом виде плохо работает в проектах внедрения продуктов 1С.

18.05.2020    11771    MariaTemchina    33    

Такие разные франчайзи. Часть вторая: Особенности реализации крупных проектов, Глава 1. О людях Промо

Управление проектом Бесплатно (free)

Продолжаем публикацию цикла статей о бизнесе франчайзи 1С. В предыдущих статьях мы рассказали о наиболее распространенном мнении о фирмах франчайзи 1С, об истории развития франчайзинга. Поставили вопрос о выборе системы мотивации. Предыдущие публикации вызвали оживленное обсуждение. В продолжении темы расскажем о том – как выглядит работа проектного подразделения фирмы-франчайзи. Расскажем на примере проектного офиса ВЦ «Раздолье». Предложим обсудить проблемы, с которыми приходится сталкиваться в проектном бизнесе. Автор статьи Андрей Мироненко.

18.04.2017    32775    1СERP    189    

Кто здесь? Или как проводить онлайн-совещания

Управление проектом Управление командой Бесплатно (free)

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

23.03.2020    6472    MariaTemchina    24    

4 причины, почему проекты никогда не завершаются в срок

Управление проектом Бесплатно (free)

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

03.03.2020    7055    VLikhobabin    44    

7-ой PMBoK - конец классического проектного управления? Часть 1-ая

Управление проектом Waterflow Бесплатно (free)

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

23.01.2020    22420    MariaTemchina    8    

Такие разные франчайзи, или как мы делаем большие проекты на 1С. Часть первая: ты помнишь, как всё начиналось Промо

Управление проектом Бесплатно (free)

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

10.04.2017    32867    1СERP    107    

1С СППР, как инструмент по внедрению, разработке и сопровождению информационных систем

СППР Управление проектом Бесплатно (free)

Система проектирования прикладных решений (СППР) – инструмент от фирмы «1С», который позволяет проектировать конфигурации, вести по ним полную документацию в разрезе объектов системы, собирать требования на реализацию и выдавать на их основе детально описанные задачи программистам. Как правильно использовать СППР при работе с многосоставной командой, на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «Иритум» Роман Кальмансон.

09.01.2020    9277    roman72    0    

Про одну Тётю

Управление проектом Бесплатно (free)

Суровое челябинское распределение ресурсов

24.12.2019    6980    1c-intelligence    33    

20 мыслей об ИТ-проектах. Мысль №3. "О правильных требованиях к системе"

Управление проектом Бесплатно (free)

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

14.10.2019    6126    chavalah    16    

Мотивация персонала в фирмах франчайзи: а она работает? Промо

Управление проектом Бесплатно (free)

Думаем, что практически любого работающего человека интересует вопрос мотивации. Этой проблемой в одинаковой степени озабочены работники и работодатели: как мотивировать людей, сколько платить, как платить, какая часть оплаты должна быть фиксированной, а какая зависеть от результата работы, как это всё повлияет на результаты работы, стоит ли быть строгим и дотошным руководителем или нужно активно делегировать полномочия подчиненным. ВЦ "Раздолье" провело небольшое исследование на тему мотивации и вот его результат. Автор статьи Андрей Мироненко.

03.04.2017    44066    1СERP    231    

Незакрытый проект на 1000 часов

Управление проектом Россия Бесплатно (free)

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

19.09.2019    13023    ogroup    164    

Мастер-класс СППР

Управление проектом СППР Бесплатно (free)

Сергей Наумов, в прошлом разработчик подсистемы бюджетирования в конфигурации «1С:ERP», на мастер-классе конференции INFOSTART EVENT 2018 EDUCATION поделился опытом управления проектами с помощью «1С:Системы проектирования прикладных решений» и показал, как использовать эту программу в работе над разными задачами: для сбора, классификации и хранения требований; для управления разработчиками и консультантами; в качестве системы документирования; в качестве баг-трекера на этапе опытно-промышленной эксплуатации.

30.08.2019    14233    SergeyN    10    

Эволюция пользовательской документации 1С в производственной компании

Пользователю системы Управление проектом Бесплатно (free)

В идеале пользовательскую документацию надо создавать под каждый отдельный проект, менять и актуализировать ее, если в функционале что-то изменилось. Но чаще всего в организациях документацию считают неэффективной, поэтому даже не разрабатывают ее, либо документация имеется, но ее никто не использует, так как она устаревшая. Какие шаги надо предпринять, чтобы заинтересовать пользователей документацией и одновременно снизить нагрузку на консультантов 1С, рассказал руководитель службы технической поддержки в ГК «Доброфлот» Арсен Сазандрашвили.

20.08.2019    9541    Arsen1986    7    

Про спагетти, или как исследовать бизнес-процессы организации Промо

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

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

23.02.2017    28095    Gavrik    10    

Управление проектами по автоматизации бюджетирования

Управление проектом Финансовый учет и бюджетирование (FRP) Финансовый учет и бюджетирование (FRP) УУ Бесплатно (free)

Автоматизация бюджетирования позволяет максимально эффективно планировать ресурсы предприятия и управлять масштабированием компании. Как учесть особенности бюджетирования, встроить его в процессы стратегического планирования, чтобы получить гибкий инструмент управления и аналитики, рассказал Сергей Наумов на конференции INFOSTART EVENT 2018 EDUCATION.

28.06.2019    8745    SergeyN    1    

Внедрение решений: как выполнять все обязательства в срок в условиях ограниченных ресурсов

Управление проектом Бесплатно (free)

Многие менеджеры вынуждены работать в условиях многоклиентской среды с ограниченными ресурсами. И вовремя сдавать проекты в таких условиях сложно. Как добиться того, чтобы поставки делались без нарушений сроков, рассказал гостям и участникам конференции Infostart Event 2018 управляющий партнер BIPULSE.RU Алексей Васильев.

24.06.2019    7071    sbase    9    

Цифровая трансформация. Будущее учетных систем

Управление проектом Россия Бесплатно (free)

О цифровой трансформации слышали все, но немногие в этом разбираются. Что она собой представляет, какие несет изменения, на что надо обратить внимание айтишникам и 1С-никам, рассказал на конференции руководитель департамента автоматизации строительных организаций компании «Первый БИТ» Иван Аверьянов.

19.06.2019    10667    FB_10160810658600104    62    

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

Управление проектом Бесплатно (free)

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

17.06.2016    40679    raiml    37    

Риск - благородное дело!.. Часть первая

Управление проектом Бесплатно (free)

Несколько рекомендаций по управлению рисками в ИТ-проектах.

18.06.2019    8015    MariaTemchina    8    

Мы в ответе за то, чего вовремя не послали. Матрица ответственности в проектах внедрения

Управление проектом Бесплатно (free)

В своей публикации “Устав писать Устав” я много рассуждала о том, как полезно умение договариваться на берегу. Как известно, у каждого человека в голове своя картина мира. В целом, многие конфликты в ходе проектов происходят как раз из-за конфликта ожиданий, и из-за нечетких договоренностей, кто чем должен заниматься.  

31.05.2019    10565    MariaTemchina    23    

Как мы со Стасом завод за 2 месяца автоматизировали

Управление проектом Бесплатно (free)

Мой опыт быстрого внедрения.

14.05.2019    11643    1c-intelligence    121    

Практические вопросы внедрения и развития автоматизации склада Промо

Управление проектом Бесплатно (free)

Мне, как одинэснику, не приходилось заниматься какими-то узкими задачами «от сих до сих». Вся моя профессиональная деятельность, как одинэсника, была всегда связана с очень широким кругом вопросов. Наверное, потому, что я работал, в основном, в малых компаниях, где приходилось работать над всем спектром вопросов.

26.12.2014    45342    CheBurator    64    

Устав писать Устав

Управление проектом Бесплатно (free)

Ответы на вопросы про то, нужен ли Устав для проектов автоматизации, и если нужен, то зачем?

06.05.2019    8175    MariaTemchina    8    

Как сжать время?

Управление проектом Личная эффективность 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Как, и зачем измерять задачи в чем-то, помимо часов.

04.05.2019    9157    1c-intelligence    39    

Путь джедая в управлении проектами 1С: умение быть, а не казаться

Управление проектом Бесплатно (free)

Чем руководитель проекта “на бумаге” отличается от “настоящего” руководителя проекта, умеющего направлять команду и выдавать ценный результат?

15.04.2019    12724    MariaTemchina    15    

Практика пуска склада продуктов питания Промо

Бухгалтерский учет Управление проектом Оптовая торговля, дистрибуция, логистика 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Описывается опыт пуска склада (охлажденная и замороженная продукция) с точки зрения IT. Со временем из складского подразделения была создана компания, которая оказывает логистические услуги (3PL-оператор) сторонним Клиентам.

1 стартмани

14.09.2015    36597    axxell    15    

20 мыслей об ИТ-проектах. Мысль №2. "С какой стороны подойти к новому проекту?"

Управление проектом Бесплатно (free)

Продолжаем серию статей из цикла “20 мыслей об ИТ-проектах”. Сегодня мы поговорим о том, с какой стороны подойти к новому проекту. Такой вопрос возникал у каждого, кому приходилось выступать в роли руководителя проектов, особенно первый раз. Да и для опытных РП некоторые проекты вызывают аналогичный вопрос.

13.02.2019    8464    chavalah    22    

Стыд и скрам - Чему нас учит Scream Guide

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Название "Scream Guide" можно вольно перевести на русский как “Вопль ужаса от того, как Scrum применяют на практике”

12.02.2019    10815    MariaTemchina    20    

Бизнес, не горюй

Управление проектом Бесплатно (free)

Про цели автоматизации.

04.02.2019    10425    1c-intelligence    64    

Как теряют бизнес. Реальные истории от бизнес-консультанта. Промо

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

Поговорить о том, какие причины способствуют гибели существующего и часто даже успешного на определенном этапе бизнеса, я планировал давно, но все не доходили руки. Но недавно я услышал о банкротстве моего, теперь уже, клиента. Именно этот факт стал для меня неким толчком. Я осознал, что именно сейчас, в условиях кризиса очень важно понимать, почему бизнес может окончиться крахом и учиться избегать подобных ситуаций. Как известно, когда в экономике кризис, любой бизнес ослаблен. Если сравнивать с человеческим организмом, то кризис для экономики – как ослабление иммунитета. Когда человек здоров, то мелкие болезни проходят незамеченными. Организм сам справляется с проблемами, а в случае ослабления иммунитета, любая инфекция может привести к серьезным заболеваниям или даже стать фатальной. Так происходит и в бизнесе. Если в период подъема экономики какие-то недостатки конкретного бизнеса сглаживаются, остаются незамеченными и даже не слишком мешают работать, то в периоды экономического спада они становятся теми самыми «тонкими местами», которые приводят к снижению прибыли, к определенным проблемам, а иногда даже к полному краху всего бизнеса.

06.04.2015    38108    raiml    14    

Лучший домик для поросенка, или Что нужно знать руководителю проекта внедрения

Управление проектом Бесплатно (free)

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

31.01.2019    8503    MariaTemchina    0    

Что немцу хорошо, то русскому... Как минимум, небезынтересно. Продолжаем тему Канбан

Управление проектом Бесплатно (free)

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

14.01.2019    10574    MariaTemchina    13    

20 мыслей об ИТ-проектах. Мысль №1. "О незаменимых людях"

Управление проектом Бесплатно (free)

Этой статьей начинается цикл из 20-ти обещанных мыслей об ИТ-проектах. Надеюсь, что по прочтении кто-то посмотрит на проблему незаменимых людей с другой стороны.

10.01.2019    13360    chavalah    124    

Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть II Промо

Управление проектом Бесплатно (free)

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

16.11.2014    28989    raiml    46    

Где мы взяли флакон?

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

История появления и развития методики

26.12.2018    10267    1c-intelligence    7    

Озарение после прочтения макулатуры по проектному управлению

Управление проектом Бесплатно (free)

Открываю этой публикацией мини-рубрику "Письма в редакцию". По мотивам очередной статьи на Инфостарте пришло мне письмо на корпоративную почту. Прямо-таки, крик души. С разрешения автора, решила опубликовать публичный ответ. Ибо согласна с автором письма, пишущим: "Я уверен, что не я один такой убогий, кто задается подобного рода "идиотскими" вопросами, но при этом почему-то все молчат, видимо, pmbok с agile-ом поистине творят чудеса молчания..."

19.12.2018    10283    MariaTemchina    24