Проблемы оценки ИТ-Проектов

14.04.15

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

Данная статья написана по материалам доклада, прочитанного автором на Конференции Инфостарта IE 2014 29-31 октября 2014 года. В статье три части. • Первая часть посвящена тем методам оценки, которые встречаются на практике, в том числе, которые я использую. • Во второй части мы разберем наиболее часто встречающиеся ошибки при оценке проектов. Их много, и я собрал десяток наиболее важных. • И в третьей части мы поговорим об оценке рисков.

В чем заключается проблема оценки проекта?

 

Для начала нужно понять, в чем заключается проблема оценки проекта? Откуда она вообще берется?

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

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

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

 

Методы оценки проектов

Поэтому для начала мы поговорим о тех подходах к оценке проектов, которые встречаются на практике. Когда я проанализировал все свои проекты за последние годы (в том числе и те, которые я выполнял с другими командами), у меня получилось всего 9 подходов.

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

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

Первый метод – я его называю «Три П». Это такой полушуточный метод, который, несмотря на то, что он полушуточный, достаточно часто встречается.

Что же это за метод? Тут нарисована подсказка – пол, палец, потолок.Это вроде как смешно, но такой метод очень часто используется, особенно тогда, когда люди просто не знают, какую стоимость назвать: «а давай скажем вот так».

Что в этом методе хорошего?

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

Правда, есть существенные недостатки:

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

И второй момент – если заказчик спросит, как мы получили эту стоимость, то объяснить будет очень тяжело: «просто у нас такие цены» – больше сказать будет нечего.

Следующий подход – это оценка по аналогии.

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

Что в нем хорошего?

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

Но на самом деле, недостатков в таком подходе еще больше.

  • Потому что построить подобную базу с адекватной информацией – это очень сложно.

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

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

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

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

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

Какие тут достоинства?

  • Если человек, который оценивает компетенции команды, достаточно опытен, то точность оценки получается довольно высокая. По крайней мере, я, пользуясь таким подходом, ни разу существенно не ошибался.
  • Оценка достаточно быстрая;
  • И, что самое главное, такая оценка получается конкурентной по сравнению с промышленными подходами, когда мы сначала проект оценили, его продали, а потом уже будем думать, кто и как это будет реализовывать (процессы оценки и подбора исполнителей разделены). Соответственно, при использовании метода«Экспертно по компетенциям» будет получена более вероятная оценка, потому что здесь ты знаешь не только то, что нужно сделать, но также и точно знаешь компетенции участников команды, знаешь, что эти люди есть и действительно смогут выполнить задачи в определенные сроки.

Но есть и недостатки:

  • Потому что в распоряжении руководителя проекта здесь появляется уже определенная фиксированная команда. Но команда – это люди, «человеческий фактор» никто не отменял. Есть риск, что могут возникнуть сложности (заболеть, уволится). Поэтому нужно закладывать какой-то запас ресурсов на этот случай.
  • Также могут возникнуть сложности в обосновании полученной оценки заказчику, особенно если это госструктуры, которые начинают задавать вопросы: распишите структуру цены, как вы это получили и т.д. Это сделать можно, но уже придется разъяснять.

Следующий подход я назвал «За сколько купят». Он тоже встречается.

Допустим, у нас есть какая-то инсайдерская информация, и мы знаем, что у заказчика на проект потенциально заложен такой-то бюджет.

  • Следовательно, даже если нам самим эта сумма кажется недостаточной для реализации такого проекта, мы все равно можем быть уверены, что если наша оценка приблизительно попадет в эту цифру, то, скорее всего, заказчик будет доволен.
  • А уже потом, предварительно поработав с ним, поговорив, объяснив некоторые вещи, мы сможем повлиять на его ожидания и скорректировать требования.
  • Фактически, мы можем сразу же делать заказчику предложение по реализации такого проекта, который бы заведомо вписывался в этот бюджет – достаточно велика вероятность, что мы угадаем, и ему это понравится.

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

Из недостатков:

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

Следующий подход – я его назвал «Сметный».

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

Достоинств у такого подхода больше, чем минусов, но минусы, тем не менее, есть:

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

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

Это, конечно, идеальный вариант, и он наиболее прост в оценке. Здесь предполагается, что предварительно перед проектом:

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

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

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

А из недостатков:

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

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

Дальше –несколько слов о научных методах. Их всего три:

  • PERT;
  • Метод функциональных точек;
  • И COCOMO (ConstructiveCostModel) – конструктивная стоимостная модель.

Подробно рассказывать обо всех не буду. Все методы западные, появились достаточно давно, в 50-80х годах. Эти методы предназначены для оценки программных проектов, но, на мой взгляд, применять их на практике в нашей жизни очень сложно. И, хотя в Профкейсе от 1С метод PERT и метод функциональных точек упоминаются (там даже предлагается некая методология по обоснованию их применения), но я об этом сейчас рассказывать не буду, потому что я ни разу не видел применимости этих методов в реальной жизни. Мне кажется, что даже если попробовать их применить для проектов на 1С, то для их адаптации явно придется провести очень серьезную работу.

 

Типичные ошибки при оценке

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

 

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

  • Нужно постараться приложить как можно больше усилий для того, чтобы перед ответом на вопрос «Сколько это будет стоить?» сначала  понять, что же конкретно мы должны сделать. Очень большая ошибка - вписываться в проект, требования к которому слишком общие, потому что правильно оценить его практически нереально (либо нужно заведомо закладывать большие риски).
  • При этом нужно обязательно учитывать, знаем ли мы те технологии, которые предполагается использовать в проекте. Допустим, если результат должен опираться на какие-то новые технологии, которые мы ни разу не использовали, но нам кажется, что они работают – это вовсе не означает, что все будет так просто, как мы хотим.

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

Вторая ошибка – это полагаться при оценке только на сформулированные заказчиком требования.

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

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

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

Также часто встречается ситуация, когда оценка делается только силами менеджеров по продажам. Например, на одной из конференций (на партнерском семинаре 1С) выступал коммерческий директор одной из крупных фирм-франчайзи 1С, который говорил, что ему не нужны руководители проекта для оценки, он сам лучше них может все оценить и продать.

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

И обратная ситуация – когда оценка ведется только силами технических специалистов.

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

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

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

  • Нужно учитывать ошибки и находить для себя наиболее  подходящий вариант.
  • Лучше применять те методы, которые давали хороший результат.
  • Излишнюю бюрократию тоже устраивать не нужно. 

 

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

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

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

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

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

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

Как говорится, в проектном управлении есть такая маленькая шутка – следствие закона Мерфи: «Если в проекте что-то может пойти не так, оно обязательно пойдет не так».

 

Оценка рисков

 

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

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

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

 

Заключение

 

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

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

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

***************

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

См. также

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

Кейсы проектов Бесплатно (free)

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

20.12.2023    2771    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

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

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

05.07.2023    14301    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

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

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

28.06.2023    5852    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

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

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

10.02.2023    4699    0    andironenko    2    

31

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    2746    0    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

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

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4185    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

09.09.2022    10667    0    biimmap    79    

75

Как донести здравый смысл до заказчика. Инструменты архитектора

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

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    13091    0    Evil Beaver    17    

117
Вознаграждение за ответ
Показать полностью
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Steelvan 302 14.04.15 15:15 Сейчас в теме
2. chavalah 1073 15.04.15 01:09 Сейчас в теме
(1) Steelvan, Игорь, привет! Необычное место для "поздороваться"))
3. dag903 15.04.15 10:18 Сейчас в теме
Статья содержательная. Все оценки и риски разложены по-полочкам. В своей практике обычно я все возможные риски закладываю в договор. Как например, у Вас есть описание в одной из ошибок - изменение процессов в ходе реализации проекта. Наверно самый распространенный риск, если разложить его на количество внедрений.
Я всегда руководствуюсь двумя правилами:
1. "Что для Заказчика СЛОЖНО - значит для Исполнителя будет ПРОСТО. И наоборот. Что для Заказчика ПРОСТО - для Исполнителя ОЧЕНЬ СЛОЖНО". Например, если Заказчик говорит (очень утрировано): "Мне надо чтобы я нажал одну кнопочку и всех была вся информация, все пересчиталось, СМС отправлены, письма всем клиентам отправлены, отчеты на мониторе у руководителя". Значит я понимаю, что придется попотеть, чтобы выполнить его требования. Соответственно, закладываюсь на увеличенное количество работ + привлечение квалифицированных специалистов. И таким образом обосновываю стоимость работ. Но если мне Заказчик говорит: "Сделайте мне 1-2 отчета, мы его потом выгрузим в Excel и сами выполним все дальнейшие расчеты и т.п." Соответственно и стоимость будет небольшая. Тогда и к конечному результату претензий я не принимаю.
2. Так называемая трех-факторная модель "ДЕШЕВО - БЫСТРО - ХОРОШО". Выполняются всегда только 2 фактора, при этом третий фактор принимает противоположное значение". Вот с этих позиций и оценивать проект. Понятно, что каждый фактор величина относительная, и тем не менее....
vakham; Lacrimosa0000; &rew; +3 Ответить
4. Nikola23 696 15.04.15 11:17 Сейчас в теме
Где-то я этот текст уже видел.
Автор, вы Автор или просто перепостили?

Текст полезный? не спорю.
8. chavalah 1073 15.04.15 17:02 Сейчас в теме
(4) Nikola23, Вы ничего не курили? )) Может на Инфостарт приезжали и в зале слушали?
new_user; +1 Ответить
5. graZy 16 15.04.15 12:14 Сейчас в теме
"плюс" статья хорошая

надеюсь "заказчики" тоже со временем начнут понимать


TreeDogNight; AntonSm; monkbest; &rew; Kovalenywka; +5 Ответить
6. hostguy 1 15.04.15 14:49 Сейчас в теме
Содержательная статья, большое спасибо за то что все разложено по полочкам. Добавлю к себе в Избранное, чтобы по необходимости перечитывать.
7. Gendalf_beliy 15.04.15 15:18 Сейчас в теме
Спасибо за статью очень полезно и содержательно.
9. sergsqvo 15.04.15 22:14 Сейчас в теме
Считаю что автор описал всего 2 метода:
1. На основании опыта (пилотный проект или коммерческое предложение);
2. Составление укрупненной сметы (с максимальной детализацией за оплаченное время).
Но это не разные методы, а разные этапы проектирования.
Причем оба этапа убыточны (чаще), но нормализуют отношения с клиентом и формализуют этапы выполнения проекта.

Рекомендую ознакомится с ГОСТОМ http://www.it-gost.ru/content/view/101/51/

:)

В идеале лучше разделить программистов и аналитиков. Хотя и сыр и масло и сливки - молочные продукты.
vakham; aleksashin; +2 Ответить
10. Gesperid 2 16.04.15 15:51 Сейчас в теме
(9) sergsqvo, так всё таки считаешь, что описал два метода?
13. chavalah 1073 17.04.15 04:19 Сейчас в теме
(9) sergsqvo, а что там в ГОСТе про оценку сказано?
11. SunShinne 633 16.04.15 20:52 Сейчас в теме
Замечательная статья. Добавил бы еще три нюанса при оценке проектов:
1. Загруженность очереди проектов. Если работы мало - демпингуем, если работы много - задираем ценник повыше и меньше тратим времени на ухаживание за Заказчиком
2. Стратегическая важность проекта. Например если хотим зайти на новую отраслевую специфику, или Заказчик уж очень перспективный для будущих задач, то иногда стоит снизить ценник.
3. Объективно отлаженные технологии позволяют держать низкий ценник и сохранять достойную рентабельность - но требуется специализация, что, в свою очередь, требует отлаженный процесс продаж и масштаб.
vakham; Lacrimosa0000; &rew; Steelvan; +4 Ответить
12. Steelvan 302 16.04.15 22:41 Сейчас в теме
14. chavalah 1073 18.04.15 16:34 Сейчас в теме
(11) SunShinne, Да, все 3 пункта справедливы. Но с "меньше тратим времени на ухаживания за Заказчиком" надо осторожнее, чтобы не сказалось на качестве и репутации. Иногда лучше совсем отказаться, чем сделать плохо.
15. AlexO 135 20.07.15 10:46 Сейчас в теме
(11) SunShinne, (14) ну так, и по какому методу оценивать? По 6-ти, по 3-м, по 1-му? И как затраты на оценку - лягут потом в общие расходы?
16. chavalah 1073 05.11.15 08:38 Сейчас в теме
(15) AlexO, по поводу затрат на оценку я говорил на круглом столе на позапрошлой конференции. Советую придерживаться следующего подхода:
- если продажа состоялась, относить затраты на проект;
- если продажа не состоялась, относить затраты на общие затраты по продажам, т.е. на само направление продаж (отдел например, или компанию в целом - от структуры компании зависит).

А оценивать надо тем методом, которым чаще угадать получилось.
17. &rew 49 28.11.16 11:07 Сейчас в теме
Добрый день!

По оценке проекта. Я оцениваю по личному опыту плюс 30% на непредвиденные (30% могут и не появится, т.е. опционально, о чем заказчик предупреждается заранее). Но это что касается, когда проект веду я. Когда начинаешь оценивать со своей колокольни, отдавая его другому исполнителю, то тут просто пальцем в мимо. Соответственно вопрос в оценке уровня компетенции исполнителей. Как с этим вопросом быть? Наличие сертификатов не в счет, иногда такие дубы колдуны с сертификатами попадаются...
18. chavalah 1073 28.11.16 15:44 Сейчас в теме
(17)Добрый день, Андрей,

Проблема известная, сталкивался с таким. Я когда оценивал, всегда исходил из того, своей командой делать, или это просто оценка. На конференции упоминал об этой проблеме. Раз Вы умеете оценивать для себя, значит сможете и для других. Что делать: наиболее подходящим в такой ситуации является метод, который я назвал "сметный" (№5 в презентации). Еще лучше сделать оценку несколькими специалистами, затем сравнить.
19. &rew 49 02.12.16 10:25 Сейчас в теме
(18) Проблема мне видится шире. Нет у нас в стране четкого понимания стоимости АйТи услуг у владельцев бизнеса. Я бы даже сказал хотя бы уровня затрат на АйТи. Многие относятся к этому как к неизбежному злу, а не как к реальной помощи и сокращению издержек (не будем употреблять слово Затарт). Посему оценка специалистом который даст меньше, будет заказчиком восприниматься как более объективная.
20. user866649 21.11.17 17:13 Сейчас в теме
А где ищут(компания или специалист) оценщиков web-проектов или специалисты, которые проводят экспертизу в 1С-проектах, справятся?
21. chavalah 1073 22.11.17 14:32 Сейчас в теме
(20) Хотя технологии оценки аналогичные, все же это разные проекты, разный опыт требуется. Необходимы компетенции именно в аналогичных проектах. Поэтому для WEB-проектов лучше к студиям разработки сайтов обращаться.
22. Leon75 15.02.21 19:00 Сейчас в теме
Из своего опыта скажу. Знаете что было бы,
если бы вы обладали сверхспособностями
как у доктора Манхеттена
и называли бы с точностью до минуты время проекта?
Вы думаете вы бы были нарасхват?
К вам бы перестали обращаться.
Слились бы как в игре на пабе.

А так да, весело.
Вы же не только от техкомпетенций
отталкиваетесь, но и от
* ограничений платформы
* ограничений режима совместимости
* ограничений СУБД
* ограничений настроек сервера
* чужого API (который без поддержки и не очень то работает)
* непонятного и уникального оборудования (контроллеры доступа)
* ИТ персонала
* доступа к месту разработки(вас могут не пустить, выключить сервер разработки.)
* вас могут дезинформировать о состоянии системы (ой а там такого быть не должно.../ ой а там должно быть по-другому)
* вам могут не давать говорить
* вас могут не слушать
* могут быть предложения сделать в одиночку (а внедрите ка нам ЕРП2 на завод. Ну да сами. Ну да скачали с интернета. Ну да, месяца вам хватит?)
* и вишенка на торт - вам могут не дать оценить трудозатраты. (Так любой дурак может, вы нам сразу скажите)
Вот такая вот реальность. С абсолютно незнакомыми людьми.
vakham; WKBAPKA; +2 Ответить
23. roman72 379 08.01.23 23:59 Сейчас в теме
Вот здесь про метод COCOMO(II) поподробнее
https://infostart.ru/1c/articles/1176530/
Оставьте свое сообщение