gifts2017

Гибкий Стандартного разумеет?

Опубликовал Александр Белов (AlexWhite) в раздел Управление - Управление проектом

Об опыте стандартизации методики управления распределенными программными проектами на платформе 1С:Предприятие и сертификации СМК по ISO 9001:2008

Я занимаюсь автоматизацией предприятий на платформе 1С с использованием собственной технологии оказания внедренческих услуг, которую считаю гибкой по сути.

Что имеется в виду под понятием «гибкая технология»?

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

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

Каждая итерация – это отдельный минипроект, выполняемый по каскадной модели:

  • Анализ,
  • Уточнение,
  • Разработка,
  • Тестирование,
  • Передача.

Мы используем недельные итерации. Длительность итерации подобрана опытным путем. В рабочий месяц умещается 4 результативные итерации. 

Гибкие методики – упреки и заблуждения

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

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

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

Гибкие методики – преимущества

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

Обратите внимание, когда нужно – выработка почти 700 часов в месяц. Когда не нужно – выработка почти 0 в месяц.

Нам удалось, например, работая по нашей технологии, разработать систему управления складом (WMS) за 90 дней и сэкономить заказчику 2000 долларов на каждом рабочем месте.

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

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

Как все-таки увеличить степень доверия к нашей технологии для новых заказчиков? Так пришло решение о сертификации нашей системы управления качеством на соответствие международному стандарту ISO 9001-2008.

Я знаю, что есть проектные организации, у которых по ISO сертифицирована система управления качеством для "водопадного" процесса разработки. Нам сложнее. Как стандартизировать работу, которая во многом построена на субъективных критериях оценки качества, работа ведется по гибкой технологии, без технического задания, в частности?

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

Отсюда родился слоган:

  1. Требуемая функциональность
  2. К ожидаемому сроку
  3. За приемлемую плату.

Нижние два критерия сильно субъективны.

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

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

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

Область сертификации по ISO  

Структура деятельности нашей организации:

  • 94% – основная деятельность - комплексное обслуживание 1С:Предприятие, включая программирование (разработка, проектирование, внедрение систем),
  • 2% – это продажи программных продуктов,
  • 4% – это информационно-технологическая сопровождение (ИТС).

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

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

Но в нашей деятельности эта область составляет 2% +4%=6%. Мы добавили в формулировку «проектирование, разработка и ввод в эксплуатацию», чтобы охватить областью сертифицации оставшиеся 94% нашей деятельности.

Сертифицируемый стандарт взаимодействия с заказчиком

 

Если раньше система управления качеством находилась в головах сотрудников, для сертификации СМК пришлось ее описать. Схема приведена в качестве примера.

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

  • анализ достижения понимания требования,
  • разработка,
  • тестирование
  • и внедрение.

Осталось получить подтверждение сертифицирующего органа, что этот стандарт соответствует требованиям международного.

Процесс сертификации  

 

49 с половиной недель - можно сказать, почти "эротическое путешествие" :-)

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

Для сертификации нами пройдено:

  • Подготовительный этап  – 8 недель.
  • Анализ «Как есть» (анализ и описание нашей технологии) – 4 недели.
  • Разработка документации для системы управления качеством – самый длительный этап, 20 недель.
  • Само внедрение СМК – порядка 9 недель. На этом этапе все те документы, которые были разработаны для нашей системы управления качеством, надо было добавить в наш процесс, причем так, чтобы это не было навязыванием, чтобы люди согласились их использовать, чтобы это органически вплелось в нашу организацию. Это был достаточно сложный процесс.
  • Внутренний аудит – мы уложились в 4 недели.
  • 4 недели - внешний аудит.

В конечном итоге получилось 49 с половиной недель (чуть меньше года).

 

Комплект документов получился чуть-чуть меньше 22 см в толщину. Причем, как мы потом узнали на внешнем аудите, можно было сделать примерно в половину меньше.

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

 

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

  • Наличие у нас системы управления качеством, эксплуатируемую нами с 2005 года;
  • Наличие полностью документированных отношений со всеми заказчиками по всем проектам, по всем задачам от момента анализа до момента передачи через разработку и тестирование;
  • Заинтересованность руководства во внедрении СМК – естественно, я был заинтересован в этом деле больше всего, как руководитель;
  • Обеспечение СМК (системы менеджмента качества) необходимыми ресурсами – очень важный фактор. Если бы я не взял специального человека (специалиста по внедрению), вряд ли смог бы самостоятельно выделить время для того, чтобы все это провернуть в свободное от основной деятельности время. Если вы вдруг соберетесь сертифицироваться по ISO, важно понимать, что для этого нужен определенный ресурс, причем человек достаточной квалификации;
  • Электронный документооборот;
  • Система управления требованиями,
  • И доступность документов СМК.

Заключение

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

 

 ******

Данная статья написана по материалам доклада, прочитанного автором на Конференции Инфостарта IE 2014 29-31 октября 2014 года.

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

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Dim Dragonim (Dragonim) 19.01.15 15:05
Давайте я расскажу вам, почему ваши заказчики довольны здесь и сейчас, и почему они вас проклянут, когда вы уйдёте.

Они довольны потому что:
1. Заказчик обожает людей, которые просто приходят и делают, так как он сказал, результат через неделю. Разрабатывать техническое задание на всю систему долго и сложно, необходимы люди со стороны заказчика и исполнителя. Это время и деньги. Намного приятней, когда директор говорит «Сделайте мне вот эту рюшечку», а заказчик делает.
2. Заказчик обожает платить за проделанную работу, а не за ту, которая будет сделана. Очень часто хорошее продуманное тех задание дороже и трудозатратней чем вся оставшаяся работа. Для многих заказчиков это выглядит как плата за воздух.

Заказчики проклянут вас потому что:
1. Итоговая работа по сиюминутным требованиям будет дороже, чем та же работа по продуманному тех заданию.
2. Если заказчик сядет и подсчитает время, которое затратил, то поймёт что продуманное тех задание было сделать быстрее, чем каждый раз указывать вам что ему ещё хочется.
3. В итоге заказчик получает систему с большим количеством ненужных модулей которые никогда не будут использоваться и не до конца оптимизированными и автоматизированными другими функциями, которыми он пользуется.

Это только то, что пришло на ум сейчас и сразу, если заглянуть в глубь, там всё ещё печальней.

PS. В самом начале вы приводите диаграмму работы с заказчиком над его системой в течении 8 лет, а ниже пишите «разработать систему управления складом (WMS) за 90 дней и сэкономить заказчику 2000 долларов на каждом рабочем месте». Получается вы за 3 месяца сделали базовую функциональность WMS, сэкономили заказчику 2000 долларов, а после допиливали вашу поделку ещё 94 месяца, т.к. переплата времени и денег колоссальна. Могу с уверенностью говорить, что за 3 месяца заказчик может выбрать и начать внедрять устоявшуюся и продвинутую WMS систему, а после стабильно и без потери времени и денег на ней работать.
2. Евгений Сосна (pumbaE) 19.01.15 16:40
(1) Чем это лучше - заказчик купил WMS в которой все есть и потом 94 месяца пытается ее у себя внедрить, а консультанты консультируют "это все есть, просто вы не умеете пользоваться", а в результате натягиваем бизнес процессы предприятия на модель WMS?

p.s.: давайте в споре опустим момент, что навороченная WMS самая правильная и разрабатывалась она для одних типов складов, а продали для другого... (например мелкая и крупная фасовка).

p.s.s: http://youtu.be/cmyZzsfiues?t=5m3s
byte.mdfab; ZLENKO; +2 Ответить
3. Сергей (Che) Коцюра (CheBurator) 19.01.15 18:09
Вставлю свои пятьдесят копеек, так как промолчать не могу (ввиду имеющегося опыта работы по складским технологиям).
Дабы не быть рамилем, буду пояснять все на себе.

Первое:
Внятное ТЕХЗАДАНИЕ (а !!техпроект!! еще раньше должен делаться) - составить весьма проблематично.
Беря свой склад - на этапе разработки техПРОЕКТА (даже не техзадания!) - несмотря на то, что склад у меня по логистике прост до безобразия и вообщем бизнесспроцессы были мной давно обсосоаны и внедрены - разработка техпроекта заналя ДВА МЕСЯЦА (примерно по 2-3 дня в неделю) - имеено потому что была попытка сделать техпроект, подробно описывающий ФУНКЦИОНАЛЬНОСТЬ wms - по факту все равно получилось достаточно обще. Во что выльется подробное ТЕХЗАДАНИЕ при такого рода работах - я даже боюсь себе представить

Второе:
Еслив конторе есть свои вменяемые программисты и есть свой вменяемый спец по складу - и склад не меняется в своей логистике/бизнеспроцессах каждые три недели - дешевле, ЛУЧШЕ и быстрее - будет написать требуемую WMS самим.

Если в конторе есть вменяемые программисты, но нет спеца по складу - нанимаем консультанта по складу и под его дудку а) пишем сами с нуля б) покупаем базовое промышленное решение и дописываем сами дальше по дудку консультанта.

Какие есть трудности: отдельные консультанты, не специализирующиеся на какой-то кокнкретной wms - вряд ли пригодятся, а если и пригодятся то на самом начальном уровне - на уровне "выпрямления" функциональности склада, ковыряться во внутренностях вмс придется программерам самим - что вообщем будет непросто... А если нанимать консультанта из самой конторы, которая продала ВМС - вряд ли вмсники будут в этом заинтересованы - потому как само базовое решение которое можно купить аs is - это процентов 30% от стоимости проетка итоговой.

4. Сергей (Che) Коцюра (CheBurator) 19.01.15 18:12
В итоге: что получилось у меня. Очень долго, некачественно допрограммирование над базовым функционалом. Приходилось практически работать тестировщиком. Выпиливание бьагов и косяков и неудобств идет до сих пор (проект еще не финиширован), хотя по факту стартанули в работу с 26 мая (колбасило всего три дня). далее более-менее нормально.
5. Сергей (Che) Коцюра (CheBurator) 19.01.15 18:14
Если на складе был "бардак" до начала его автоматизации, то подход как в публикации - мне кажется весьма оправданным - за относительно небольшую плату можно получить автоматизацию ключевых/тяжелых участков. А вот собственно СИСТЕМУ как таковую - уже "писать" потом... отдельно..
6. Евгений Сосна (pumbaE) 19.01.15 18:22
(3) CheBurator, я знал, что не удержишся. А еще прикольно, когда новые доработки ломают старые реализации и появляется необходимость в регрессионном тестировании :)
7. Сергей (Che) Коцюра (CheBurator) 19.01.15 18:44
(6) оно, оно, точно!
вот у меня cqtxfc стоит такая штука как разработка "монитор аролей" складского персонала - то есть динамическое переназначение персонала склада по участкам в зависимости от наличия заданий - так эта штука в принципе "ломает" (как я себе представляю) штатный механизм "зашел в менюшку - выбрал что делать"... и это все тестировать придется и проверять...
8. Сергей (Che) Коцюра (CheBurator) 19.01.15 18:45
Насчет внедрения ВМС - на тех участках, где у меня была спмописная вмс - внедрение большой вмс не дало никакого эффекта, даже кое-где чуток похуже стало.
9. Александр Белов (AlexWhite) 19.01.15 20:20
(1) Dragonim,
В самом начале вы приводите диаграмму работы с заказчиком над его системой в течении 8 лет, а ниже пишите «разработать систему управления складом (WMS) за 90 дней

Это абсолютно разные заказчики. WMS сделано за 90 дней прошлой весной, а на диаграмме приведен пример другого заказчика, за время сотрудничества с которым успешно решено несколько проектов. Самый короткий проект на 1С:Консолидации выполнен был за 4 недели, из которых 1 неделю выбирали инструмент, на котором делать. Другие проекты связаны с переводом заказчика от учета в УПП 1.1 на УСО и обратно на УПП 1.2 с соответствующими доработками. Если бы требовалось создавать ТЗ или техпроект, то Консолидация бы совсем не взлетела, а в проектах УПП были бы где-то в начале пути (дописка УПП 1.1).
2. Если заказчик сядет и подсчитает время, которое затратил, то поймёт что продуманное тех задание было сделать быстрее

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

Ошибаетесь, мы сначала реализуем принципиально необходимые требования, предоставляя работающее решение в кротчайший срок. К работающему решению гораздо легче высказать отклонения, устраняемые в последующие несколько итераций. Итог - существенная экономия.
За 2 месяца получилось работающее решение, за оставшийся месяц выполнили тонкую настройку и, на всякий случай, сделали резервный интерфейс, на случай задержек поставки оборудования или отказа электроники и получения возможности отработать без простоев, с использованием резервной "бумажной" технологии.
10. Dim Dragonim (Dragonim) 19.01.15 21:12
(9)
Другие проекты связаны с переводом заказчика от учета в УПП 1.1 на УСО и обратно на УПП 1.2 с соответствующими доработками.

Отличный пример "зачем нужно развернутое тех задание и почему оно экономит время и деньги".

Если бы требовалось создавать ТЗ или техпроект, то Консолидация бы совсем не взлетела, а в проектах УПП были бы где-то в начале пути (дописка УПП 1.1).

Это говорит только о том, что заказчик сам не знает что ему надо, но хочет потратить деньги, а вы не умеете писать ТЗ.
11. Евгений Сосна (pumbaE) 19.01.15 23:34
(10) Dragonim, можно посмотреть пример ТЗ?
12. Богатырев Артур (Богатырев Артур) 20.01.15 09:51
Там люди вставляли 50 и 5 копеек, а я вставлю 1 копейку... :)
Очень интересная вещь описана и честно говоря, вызывает одобрение.
Мое ощущение от описания технологии в статье - по большому счету, речь идет о том, чтобы процесс внедрения (проектирования, разработки, доработки и т.п.) продукта на одном заказчике (один большой проект) разбить на максимально возможное количество логически более-менее законченных задач-модулей (максимально атомарных и автономных). Иначе говоря, если заказчик хочет с нуля внедрить у себя скажем, бухгалтерию, то "обычный правильный путь" - это составить вначале большущий и красивейший проект (техзадание), а потом по его плану работать (я конечно, ужасно огрубляю и утрирую). А вместо этого общий проект разбивается на ряд локальных задач (действующих в рамках одного проекта-пространства) и уже каждая из них решается отдельно, атомарно, практически как мини-проект.
Что естественно легче - с маленькой задачей проще орудовать во всех смыслах. Это плюс.
Второй плюс - заказчик быстро видит результат (прогресс будет постоянный налицо - то там сделали, то тут сделали).

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

"частые изменения увеличивают срок" и "дорого из-за частых уточнений" - частично справедливо

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

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

"низкое качество кода" - не претензия вообще, т.к. качество кода зависит исключительно от квалификации конкретных программистов, а не от величины проекта.
nurpoz; AlexWhite; pumbaE; +3 Ответить 1
13. Сергей C (Storung) 20.01.15 12:14
Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. (Взято с вики).

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

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

Да много вопросов с которыми Вы наверняка уже разобрались. Поделитесь с нами Этой информацией.
14. Александр Белов (AlexWhite) 20.01.15 12:36
(10) Dragonim,
вы не умеете писать ТЗ

Умею, но отказался от использования ТЗ в 2002 году по нескольким причинам:
  • 1 Устаревает быстрее, чем успеваешь согласовать или разработать, особенно на крупных внедрениях.
  • 2 Требует значительных усилий квалифицированного персонала исполнителя и заказчика при составлении и согласовании.
  • 3 Отсутствует точный критерий приемки ТЗ (ГОСТ, либо "нра/не нра").
  • 4 Отсутствует поступательное движение к достижению целей проекта (доработки конфигураций, приемочные испытания и пр.).
  • 5 Добавляет сложности в проект.
  • 6 Научились при помощи 1С решать и внедрять быстрее, чем писать ТЗ.
заказчик сам не знает что ему надо

Заказчик ЗНАЕТ, что ему надо. К моменту начала сотрудничества с нами по УПП 1.1, этот заказчик уже пользовался услугами фирмы-автоматизатора более 1,5 лет, половина этого срока была угроблена на составление ТЗ, остаток времени на бесконечные безрезультатные доработки УПП 1.1 под особенности учета. Безрезультатные - это когда куплена УПП, а учет ведется на чем попало, только не на УПП, а надо учесть ВСЕ филиалы. В этих условиях нам удалось решить несколько значительных потребностей при помощи Консолидации, а параллельно выполнить доработки в УСО+специфика предприятия и развернуть распределенную ИБ, чтобы пересадить все предприятие на учет в УСО. Однако, через полгода эксплуатации УСО клиент вынужден был отказаться от использования этого продукта (внешняя причина), мы помогли им выполнить необходимые доработки в УПП 1.2 и перенести данные из работающей распределенной базы.
Экономия В РАЗЫ по срокам и стоимости от аналогичных проектов по классической технологии PMBoK IV.
В прошлом году засомневался, вдруг все проекты без ТЗ по нашей технологии, начиная с 2002 стали успешными случайно? При сертификации свои сомнения развеял - об этом был доклад и статья! :-)
15. Александр Белов (AlexWhite) 20.01.15 12:51
(12) Богатырев Артур,
разбить на максимально возможное количество логически более-менее законченных

У этой медали есть 2 стороны. Да, "декомпозиция" (разбиение сложного проекта на простые) - это один из инструментов управления сложностью проекта. Но чем крупнее проект, тем сложнее управлять результатами декомпозиции - вот тут и понадобилась целая система (RMS) и технология, часть которой (систему управления качеством) мы сертифицировали :-)
16. Александр Белов (AlexWhite) 20.01.15 13:31
(13) Storung,
Половина статьи не раскрывает даже базовых сложностей с внедрением технологии, вторая же зачем-то описывает процесс сертификации

Чудесно! :-) Да, первая часть доклада вводная о гибких методиках и упреках к ним. Естественно, внедряя свою технологию у себя мы с ними столкнулись, но решили (или обошли). Об этом рассказывал на первом Инфостарте в 2012 частично в докладе из которого потом была сделана статья http://infostart.ru/public/318707/ но большей частью в общении со слушателями, во время которого ответил на все заданные вами сейчас вопросы :-) Об одном из аспектов организации эффективного взаимодействия с заказчиком рассказывал на другом Инфостарте, доклад так же превратился в статью http://infostart.ru/public/318229/ .
Вторая часть статьи про сертификацию - да, так и задумывалось!
Велосипед сертифицируете?

Почти :-) Но правильнее сказать, что сертифицировал систему управления качеством собственной технологии управления распределенными программными проектами. То есть, мне удалось сначала выстроить гибкую технологию, которая отвечает на все заданные вами вопросы и сертифицировать ее систему управления качеством - об этом опыте и рассказывал в докладе/статье :-)
На недавно прошедшем Инфостарте было представлено, как минимум, 3 доклада по использованию гибких методик в проектах 1С и был организован круглый стол с ответами на вопросы заказчикам. Кто не успел задать вопрос и получить ответ во время докладов и круглого стола, успешно подсел за столик к интересующему докладчику на infostart party и допросить :-)
Да много вопросов с которыми Вы наверняка уже разобрались. Поделитесь с нами Этой информацией.

Да, с многими разобрался и делюсь со всеми, кто посещает конференции Infostart или другие конференции и семинары с моим участием, следите за объявлениями :-)
17. Александр Белов (AlexWhite) 20.01.15 14:03
(13) Storung, нашел ссылку на видео с IE 2012, доклад http://infostart.ru/video/w167565/ и общение со слушателями http://infostart.ru/video/w168182/ (чье-то пиратское видео :-) Записи кулуарных бесед, естественно, отсутствуют :-)
18. Сергей (Che) Коцюра (CheBurator) 20.01.15 16:06
Как решаете проблему когда при решении одной мини-задачи по проекту требуется учитывать/принимать во внимание тонкости другой-мини-задачи по этомуже проекту? кто это обеспечивает/контролирует? или Заказчик выступает в роли бесконечного тестировщика?

.

у себя на проекте столкнулся с тем что при реализации разных участков (по сути мини-задачи) - разработчик должен достаточно хорошо представлять структуру/архитектуру системы, заложенные базовые принципы и кучу нюансов Заказчика. По факту я только и делаю что "работаю" тестировщиком - здесь не учли вот это, в условиях такой настройки алгоритм вообще рухнет и т.д. Выбешивает страшно. особенно когда существует еще одна проклдадка между мной и исполнителем с той стороны...
19. Евгений Сосна (pumbaE) 20.01.15 16:21
исполнителем с той стороны...
а исполнитель еще говнокодит и оказывается прокладка всего лишь менеджер и не понимает что "ПолучитьЗапрос1(), ПолучитьЗапрос23()" это, мягко говоря, неправильно...

p.s. Сергей, вряд-ли тебе юнит-тесты подойдут при такой ситуации, т.к. сам разработчик должен их рисовать.
20. Сергей (Che) Коцюра (CheBurator) 20.01.15 16:49
(19) да пусть там хоть в цикле запрос выполняется
если меня устраивает функционал и быстродействие - я в код даже смотреть не буду на первых порах (а эти первая пора может быть достаточно длительная)
потому что
был опыт скидывания на сторону мелких разработок раз 4-5 (самому влом ибо тривиально и неинтересно)
не взлетело
один раз в принципе остался удовлетворен
к программисту - претензий не было
как кодер - написал красиво/хорошо, все гуд.. кроме одного...
менеджерам это давать в использование нельзя - потому что просто менеджеров жалко будет как они с этим мучаться будут...
пришлось фейсы и логику взаимодействия междумордия самому сверху накручивать.

очень тяжело быть перфекционистом.
последнее время стал принципиально давить в себе такие порывы.
если исполнители молчат/не возмущаются не стонут - ну так значит и нормуль..
однако плакать хочется когда видишь что можно сделать лучше и это эффективность работы манагмента повысит существенно..
а манагеры - молчат
либо потому что им пофиг
либо потому что не знают (лень думать как вариант) что может быть гораздо лучше...
как-то так...
21. Сергей (Che) Коцюра (CheBurator) 20.01.15 16:52
Подход Белова - вполне оправдан - и это все явственнее видно и как на разработках ПО и так и в других сферах жизни.
Везде идет подвижка причем имхо достаточно явная на оплату не результата, а процесса достижения результата.
Что лично мне не нравится, но ничего поделать с этим видимо нельзя
Так что просто будем принимать как данность/неизбежное зло.
22. Сергей (Che) Коцюра (CheBurator) 20.01.15 16:57
Мне пока явственно непонятно только одно - до какой степени декомпозиции должен дробиться проект/задача - чтобы эти минизадачи Заказчик и Исполнитель могли оценить близко к адекватности.

например - в техпроекте описан требюуемый функционал.
беремся за реализацию.

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

как найти взаипопонимание в Белов'ском подходе..?

потому что нет-нет а всплывают задачи/субпроекты когда вариант половинчатого решения - неприемлем. Или все или ничего. А такой субпроект/задача могут быть вообщем существенно трудозатратны...
23. Сергей (Che) Коцюра (CheBurator) 20.01.15 16:58
Я уже практически местаю сидеть кодером и "кодить по ТЗ"
- у вас тут программа падает!
- применяемый вами вариант использования не предусматривался ТЗ...
.
и заи...сь!
по ТЗ наШкодил, бабло получил - свободен как сопля в полете...
24. Александр Белов (AlexWhite) 20.01.15 20:09
(18) CheBurator,
кто это обеспечивает/контролирует?

Руководитель проекта с нашей стороны.
Как решаете проблему когда при решении одной мини-задачи по проекту требуется учитывать/принимать во внимание тонкости другой-мини-задачи по этомуже проекту?

В рамках одного проекта это не является проблемой, так как проектом руководит 1 руководитель проектов, способный декомпозировать требования без конфликтов. Если кто-то из разработчиков что-то поломал, выявится на этапе тестирования, будет исправлять ("кто последний, тот и папа"). Чуть сложнее, когда решение в одном проекте влияет на решение в другом проекте с другим руководителем, а изменение и тестирование прошло только в одном проекте. Поломка, возможно, обнаружится на стороне заказчика после внедрения. В этом случае применим быстрое разрешение конфликта (откатимся через CVS на предшествующую версию), а поломка будет устранена в обычном порядке, повторное внедрение "связанной" функциональности будет после успешного тестирования на обоих проектах.
Везде идет подвижка причем имхо достаточно явная на оплату не результата, а процесса достижения результата.

Ошибаешься, нам платят за результат!
до какой степени декомпозиции должен дробиться проект

В нашей технологии, декомпозиция происходит до "задачи". Задача - это относительно самостоятельный объем работы, с которым справится 1 специалист за разумный срок и разумную плату. Например, экзамен специалиста по платформе, по-моему, состоит из нескольких заданий (бух, опер, расчет + что-то теоретическое, так?) на решение отводится около 5 часов. В нашем случае, декомпозиция аналогичного задания, скорее всего, пройдет до уровня объектов - общие объекты и изменение структуры, формы и модули справочников, формы и модули документов, отчеты и все эти задачи раздельно по "компонентам" (или как там, более точный термин для v8?) - вероятно, около 12 задач, общим объемом, сопоставимых с 5 - 15 часами.
как найти взаимопонимание в Белов'ском подходе..?

О каком взаимопонимании речь? Как нам правильно понять требования? Договориться о сроках и стоимости? Самое сложное, по-моему, кроется в выявлении и правильном понимании требований. Поэтому, мы 1 раз договариваемся: "предоставьте нам возможность, организовать сотрудничество по проекту строго по технологии и вы гарантировано получите требуемую функциональность, в ожидаемые сроки, за приемлемую плату" и все - дальше 1) максимум усилий бросаем на процессы выявления и достижения понимания требований, включая интуицию, творческий потенциал, опыт, накопленный в RMS и личный, 2) оставляем минимум усилий для контроля сроков и 3) освобождаем свою голову от мыслей об оплате :-)
25. Сергей (Che) Коцюра (CheBurator) 20.01.15 23:41
Кстати тиаки да
Хочу подтвердить сказанное автором гдето выше
За время которое прошло с написания техпроекта до реализации некоторых требуемых функциональностей эти самые функциональности отмерли
Часть по административноорганизационным причинам
Часть по факту изменения обстановки
От части функционала мы временно отказались ввиду его не сильной нужности и трудозатратности реализации
Потому каквидно сто разрабы просио не вытянут

Поэтому подход что нужно то и делаем постепенно приближаясь к требуемому имент место жить
Другое дело что весьма трудно оценить бюджет в который это выльется

Опять же
Хотелось бы конечно посмотреть на написанную вмс
Но боюсь мне ее не покажут
Потому что я злобен
Привередлив
И неадекватен ;-)
26. Сергей (Che) Коцюра (CheBurator) 20.01.15 23:44
Извините за кривую грамотность
Писать с айпада еще то извращение
Поубивал бы того кто на рускую раскладку не вынес цифры и знаки препинания

Так и в проектах некоторых
Вроде все в целом работает
Но испытываешь чувство острой неудовлетворенности
27. Сергей C (Storung) 21.01.15 10:58
Главное то, что практически каждый, кто сталкивался с проектом на год и более полностью согласен с автором в той части, что сделать по ТЗ до конца проекта не получится. На сдаче каждого этапа слышу "Нам все-равно что написано в ТЗ, мы не поняли друг друга, нам нужно вот это и это". Потом начинается длительный этап согласования трудозатрат по новым задачам, изменение требований и все по новому кругу.
И каждому хочется просто получить за выполненную задачу по "факту".
Мы постоянно сетуем на то, что жесткое урезание бюджета приводит к необходимости урезать время и на качество кода. Со всеми вытекающими.
Потому гибкий подход это хорошо, но...

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

Согласитесь, что бюджет внедрения быть должен, каждая задача должна быть согласована с заказчиком, иначе как потом доказать, что сделано именно то что он хочет? Работа без жестких требований к конкретной задаче - это рабство :)

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

Вы ведь сталкивались с компаниями, в которых внедрения хочет только руководство. Наладить тесное взаимодействие с конечным потребителем - себе же во зло. Они загонят в бесконечные рюши без функционального результата.
Реализовать основной функционал, а потом рюши? А где описано что такое основной функционал? Последовательность и сроки его реализации - ведь это же и есть постановка, которая потом становится ТЗ, Кстати, никто не заставляет написать все ТЗ в начале проекта на год в перед - только для текущего функционального блока.
28. Александр Белов (AlexWhite) 21.01.15 11:24
Хотелось бы конечно посмотреть на написанную вмс
Но боюсь мне ее не покажут
Потому что я злобен
Привередлив
И неадекватен ;-)
(25) CheBurator, тебе именно конфигурацию посмотреть хочется или экскурсию на склад организовать?
29. Александр Белов (AlexWhite) 21.01.15 12:34
(27) Storung,
Но не выходит. У клиента есть бюджет и есть резерв.

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

Соглашусь, бюджет ЕСТЬ!
Согласитесь... ...каждая задача должна быть согласована с заказчиком, иначе как потом доказать, что сделано именно то что он хочет?

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

С чего, вдруг? Жесткие требования - это рабство. В нашем случае работают здравый смысл, осознанные действия и выбор, и ответственность, вида "Взрослый vs Взрослый" (почитайте или посмотрите доклад Ирины Павленко на IER 2012).
Наладить тесное взаимодействие с конечным потребителем - себе же во зло.

Это ошибочное опасение. Поясню с позиций здравого смысла:
1. Конечный бизнес-пользователь заинтересован "освободи свое время, сохрани стабильность".
2. Руководство заинтересовано "освободи свое время, увеличив доход".
Таким образом, взаимодействие с конечным потребителем, как минимум, во благо руководству в части "освободи свое время", а когда освободит, найдет, как увеличить доход. Согласны?
Они загонят в бесконечные рюши без функционального результата

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

Мы сталкивались с очень разными компаниями, но испытали затруднение пока только с преодолением одного типа отклонений от технологии - саботаж со стороны заказчика, вида "в телегу не сяду и пешком не пойду!". Благо, такие заказчики попадаются 1 раз в год или реже :-)
Да, я еще забыл про тендеры. Зайти на проект без его бюджета просто не получится

Раньше мы отказывались от участия в тендерах. После сертификации стали участвовать. Да, в тендере, как правило, бюджет должен быть определен, а условия тендера могут существенно отличаться от нашей технологии, но это не страшно. 1) У нас есть инструмент, который при правильном использовании гарантирует получение требуемой функциональности, в ожидаемые сроки, за приемлемую плату 2) При помощи этого инструмента у нас накоплен опыт решений, начиная с 2005 года, который позволяет нам методом "аналогий" достаточно точно оценить, во сколько может нам обойтись будущее решение, если мы построим работу с ним строго по технологии. 3) Добавляем к полученной оценке управление рисками, вероятность срабатывания которых возрастает в зависимости от специфики отклонений условий тендера от нашей технологии работы 4) Оцениваем бизнес-привлекательность участия в таком тендере, если привлекательно, участвуем.
Это суть предпринимательства, по-моему: увидел вероятность получения дохода, оценил предполагаемые затраты, застраховал риски и предпринял попытку превращения дохода из вероятного в реальный :-)
30. Сергей C (Storung) 21.01.15 13:43
(29) AlexWhite,
Чтобы исключить необходимость доказательства, что сделано то, что он хочет, в нашей технологии с заказчиком согласуется первичное требование в форме воспроизводимого пользовательского примера (ВПП).

Интересный подход, хотя всех нюансов я пока не понимаю. Например стоит функциональный блок реализовать аренду. Выбрана подходящая конфигурация и началась разработка. Создан новый документ Расчет аренды и все ок. Но потом заказчик говорит, что он "предполагал" что документ будет автоматически заполнять какой-то реквизит на основании данных предыдущих периодов. Т.е. документ корректно работает с введенными данными в этот реквизит. Получить эту информацию можно из отчета. Как отсутствие этого требования может быть отражено в ВПП, если свою функционалность документ реализует.
Рюши для конечного бизнес-пользователя - себе дороже

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

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

П.С. мы почему-то отошли от темы гибкого планирования на нужно ТЗ или не нужно. Вероятно, это моя вина. И да, я считаю итерационный подход наиболее успешным и неоднократно с этим сталкивался, но, к сожалению, это единичные случаи в мой практике, которые я считаю успешными. И считаю, что ТЗ, ВПП или постановка не противоречат итерационному подходу. Но я так и не понял как уговорить клиента, что это хорошо и обезопасить себя от этого хорошо :)
31. Сергей (Che) Коцюра (CheBurator) 21.01.15 14:27
(28) было бы хорошо и экскурсию на склад организовать это в первую очередь
Посмотреть как это работает вживую, посмотреть на живой процесс

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

Со своей стороны если будет интерес можно будет на мой склад организовать экскурсию если руководство добро даст
Но сейчас не особо показательно будет так как загрузка очень маленькая и всю динамику не особо видно будет
32. Сергей (Che) Коцюра (CheBurator) 21.01.15 14:28
Вдогонку
Почему хочется посмотреть на склад и на конфигу и на работу - чтобы оценить насколько сильно я у себя на проекте промахнулся
33. Сергей (Che) Коцюра (CheBurator) 21.01.15 14:36
(29) насчет впп -не согласен
Так не годится
Потому что впп может не покрывать требуемый функционал который был согласован и один или два или больше впп могут не выявить ошибку в реализации функционала
И если такая ошибка будет выявлена впоследствии то имхо доработка должна быть осуществлена за счет ранее согласованного бюджета
То есть это то что обычно называется гарантийное сопровождение
Понятно что такой срок гарантийного сопровождения должен быть не бесконечным а разумным для двух сторон
Год в этом случае представляется обоснованным сроком
Конечно многое зависит от темпа использования продукта
При активном использовании гдето и двух месяцев хватит чтобы все бяки повылазили наружу
34. Александр Белов (AlexWhite) 21.01.15 22:14
(31) CheBurator,
было бы хорошо и экскурсию на склад организовать
С экскурсией пока проблематично, но подумаю, как показать работу - видео, скорее всего, с разрешения заказчика.
35. Александр Белов (AlexWhite) 21.01.15 22:55
(30) Storung,
хочет "как было в 7-ке" или где-то где было у них еще. Вы можете это называть саботажем

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

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

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

Отказаться от ТЗ? Одно из назначений ТЗ - переложить ответственность за сделанное решение на заказчика, застраховав себя от риска изменения состава требований до момента оплаты выполненных по ТЗ работ либо облегчения процесса согласования доп.оплаты реализации требований, которые появятся сверх ТЗ. Но какой смысл в трате времени на ТЗ, если его все-равно придется изменить или выбросить? ВПП сам по себе тоже не является панацеей, правильно работает только в рамках целостной технологии - правильная декомпозиция, правильный вопрос заказчику при выявлении, анализе и достижении понимания требования и т.д. Убеждать заказчика в том, что "гибкое" - это хорошо? Но это не факт. Я сам однажды воспользовался услугами подрядчиков, декларировавших SCRUM в своей работе, но ребята себя обманывали - "гибкость" внедрили, а про результативность забыли :-)
36. Александр Белов (AlexWhite) 21.01.15 23:13
(33) CheBurator,
Потому что впп может не покрывать требуемый функционал который был согласован

ВПП - это согласованный результат понимания требований. То есть, согласованный функционал - это один или несколько связанных ВПП. Случается, когда разработка стартует в нарушение технологии без ВПП и опыт показал, что это приводит к отклонениям в реализованной функциональности, сроках и/или стоимости, ответственность за нарушение из-за которого случилось отклонение от требуемого результата ляжет на руководителя проектов, стартовавшего разработку без согласования ВПП (наша ошибка, исправление бесплатно для заказчика). Бывает, заказчик ставит требование в формате "добавьте справочник", "добавьте субконто" или "кастрируйте скорее" - мы будем сначала искать первичное бизнес-требование ("какую бизнес-задачу собираетесь решить, жениться на еврейке?"), согласовывать его в форме ВПП, чтобы предотвратить "кастрацию" вместо "обрезания". Поэтому, следим за тем, чтобы ВПП покрывали всю функциональность, но без фанатизма, в рамках здравого смысла :-)
37. Сергей (Che) Коцюра (CheBurator) 21.01.15 23:58
(36) Это нормально и логично.
Вопрос всетаки остался. Если после "сдачи" проекта - выплывают ваши косяки в рамках ранее согласованной функциональности - но эти косяки первоначально не были отловлены ни вами, ни заказчиком - что делаете?
38. Dim Dragonim (Dragonim) 22.01.15 08:00
Сколько не читал, ваш подход мне не понятен.

Ваш подход напоминает мне строительства дома без чёткого плана. «Давайте построим небольшой домик для семьи из 4 человек. У них часто гостят друзья и родственники, давайте построим пристрой. У сына новая семья и они хотят жить все вместе, давайте сделаем второй этаж. Вот и у второго сына появилась семья, а давайте настроим третий этаж. К нам переехала бабушка, сделаем для неё надстрой над пристроим. Отцу семейства нужен свой кабинет, не вопрос, сделаем выносной. Забыли балконы на 2 и третьем этаже, сейчас достроим. Печь не может протопить дом из 3 этажей, т.к. была рассчитана на одноэтажный дом, сейчас сделаем центральное отопление. Давление воды не хватает для напора на третьем этаже, построим новую насосную станцию. Прогресс не стоит на месте и появилось центральное горячее водоснабжение, давайте у нас тоже будет. Зимой выпал снег, а крыша не достаточно покатая, под давлением снега дом рухнул к чертям, потому что фундамент рассчитан на одноэтажный дом, потому что фундамент рассчитан на одноэтажный дом, а под завалами остались покорёженное центральное отопление, центрального горячее водоснабжение и насосная станция, благо люди успели выбежать.»

Начиная проект, вы должны точно знать, на что он может быть рассчитан. Как вы это делайте без ТЗ я не понимаю. Ваше ВПП это отдельные части ТЗ, разница лишь в том, что в ТЗ описано как они связаны между собой и почему должны быть именно в той форме, в которой утверждены. Я склонен считать что ТЗ должен быть математически выверен для оптимального функционирования бизнес-процессов компании, а сами бизнес-процессы должны быть частью ТЗ. Для меня ТЗ это не перекладывания ответственности, это стремление к пониманию конечного продукта мной и заказчиком, а так же оптимизация результата во всех направлениях.
39. Евгений Сосна (pumbaE) 22.01.15 09:06
(38) покажите пример ТЗ... Не стеба ради, а для обучения.
40. Александр Белов (AlexWhite) 22.01.15 09:24
(37) CheBurator,
Если после "сдачи" проекта - выплывают ваши косяки в рамках ранее согласованной функциональности - но эти косяки первоначально не были отловлены ни вами, ни заказчиком - что делаете?

Косяки - это ошибки/дефекты? Ошибки/дефекты устраняем за свой счет, даже после завершения договора.
41. Dim Dragonim (Dragonim) 22.01.15 09:42
(39) Я бы с удовольствием, но не могу. Коммерческая тайна, а для вычистке необходимо много времени, а после несколько независимых проверок.
42. Александр Белов (AlexWhite) 22.01.15 10:31
(38) Dragonim,
Ваш подход напоминает мне строительства дома без чёткого плана.

Плохо отношусь к использованию примеров из строительства или автосервиса при утрировании управления программными проектами, так как в проектах строительства и автосервиса критерии приемки измеряемые (высота, цвет, прочность, использованный материал и т.д.). В программных проектах критерии субъективные, вплоть до "нра/ненра". Однако, описанный вами следующий пример местами вполне применим - да, если требования выявляются примерно так, как вы написали, их реализация выполняется последовательно, как вы описали, но "diablo кроется в деталях реализации" :-)
У сына новая семья и они хотят жить все вместе, давайте сделаем второй этаж.

Нет! Включаем здравый смысл: так как первоначально было требование
небольшой домик для семьи из 4 человек.
и весь расчет прошел именно в этих пределах. Поэтому для сына с новой семьей будет построен отдельный небольшой домик для семьи из 4 человек. И, скорее всего, мы его не будем строить, а Ctrl^C+Ctrl^V из ранее построенного, а пристройка для гостей вполне может остаться общей, пока ее хватает. Так понятнее? :-)
Начиная проект, вы должны точно знать, на что он может быть рассчитан.

Да, мы примерно знаем, для этого достаточно 1 встречи с клиентом, чтобы классифицировать проект по принципу, "в каком типовом решении могут быть реализованы большинство его требований?". Используя ваши примеры, мы заблаговременно определяемся, будем строить дом на 4 человек или на 50, стопиццот? :-) Есть, правда, клиенты, которым при первой встрече было достаточно домика на 10 человек, а через год уже потребовалось на стопиццот, но это тоже не проблема, так как для 10 было достаточно Консолидации, а для выросшего задействовали УПП. Повторюсь, наверное, мы не будем из мухи строить слона, а для отличия мух от слонов ТЗ не нужно! :-)
Ваше ВПП это отдельные части ТЗ

Нет, нет и еще раз да, в смысле нет! :-) ТЗ - это Техническое задание, ВПП - это Пользовательский пример (use case, user story).
Соответствие техническому заданию:
- Ребята, кто ссыл костюм?
- Я пришиваю пуговицы, к пуговицам претензии есть?
( я добавляю регистры, к регистрам претензии есть?)
- К пуговицам претензий нет, пришиты насмерть, не оторвешь. Но кто ссыл костюм?
(к регистрам претензий нет...)
В случае с ВПП:
- Спасибо, ребята, за костюм! А можно мне такой же, но с перламутровыми пуговицами?
- Да, пожалуйста, зайдите через неделю!
(через неделю):
- Спасибо! А можно, чтобы этот костюм меня от пуль защищал?
- Наденьте на него сверху этот бронежилет, когда нужно! Подойдет?
- Да, спасибо!
Я склонен считать что ТЗ должен быть математически выверен

Зачем такое ТЗ заказчику, заказавшему "я бухгалтер, веду учет нескольких предприятий, мне надо сдавать отчетность автоматически, прямо из программы"?
Зачем ТЗ заказчику, заказавшему "мы торговая фирма, несколько юр.лиц, 50 менеджеров по продажам, учет ведем в 7.7 с внедренными гибкими блокировками, боимся переходить на v8, так как наши знакомые пробовали, но уже год на матах"?
Зачем ТЗ заказчику, заказавшему "у нас производство и продажа, учетом материалов занимается 10 бухгалтеров, на складе 5 кладовщиков, уровня "Бог" или "Бог им судья!" и т.д. Сколько времени вы потратите на пытки кладовщиков, чтобы получить математически выверенное ТЗ в этом случае? Скольких из них вам придется поставить к стенке?
Зачем ТЗ заказчику с требованием "мы выпекаем хлеб, в каждую булку вставляем бутыль с самогоном, грузим в автомобиль, переправляем на Аляску через Берингов пролив и через Канаду везем в Штаты. В прошлом месяце отправили 1500 бутылок, до Штатов доехало 1000. Что делать?" Писать ТЗ? Расстрелять? Если из-за каждых 500 бутылок людей стрелять, работать не с кем будет!
По-моему, вы слишком усложняете
стремление к пониманию конечного продукта мной и заказчиком
и переоцениваете роль ТЗ в этом процессе (веду речь о проектах на платформе 1С!). ТЗ отвлекает заказчика от бизнеса на процесс понимания самого ТЗ. А ВПП возникает сам, когда заказчик при помощи работающего продукта, без отрыва от основной деятельности не может решить какую-либо свою бизнес-задачу.
43. Александр Белов (AlexWhite) 22.01.15 11:03
(41) Dragonim,
но не могу. Коммерческая тайна

О, да! :-) О том, чтобы продать что-нибудь ненужное подороже, купив что-нибудь ненужное подешевле, знает только ваш коммерческий директор, наверное? :-)
Однажды к нам обратился клиент, который заказал целой консалтинговой фирме описание бизнес-процессов, заплатив бешенные деньги. К моменту нашего прихода, у него на полке красовалось 2 томика, страниц по 500 каждый, за огромные деньги перепиленная вкривь и вкось УПП, из которой с гордо поднятой головой заказчик хвастался: "О! Я тут вижу все задачи по всем пользователям, и 3 прайс-листа!". Попросил, почитать описание бизнес-процессов, чтобы понять хотя бы масштаб требований, но фраза "нет, так как коммерческая тайна" меня несколько озадачила. Что же там такого, кроме "бери больше, кидай дальше, пока летит, отдыхай!" тайного может быть написано? Название фирм? ООО РомашкаНефтеГазСтройНикельСервис? :-)
44. Сергей C (Storung) 22.01.15 12:02
(36) AlexWhite,
А можете в двух словах описать как будет выглядеть ВПП в случае, например, следующей задачи:
Добавить новый справочник, добавить в документ, добавить новый регистр, добавить заполнение регистра на основании данных + элемент справочника и создать отчет.

В ТЗ я понимаю как это все добавить, но как будет выглядеть ВПП?

Немного не в тему ответа, но все же. Представим, что заказчик говорит, что ему не нужно выводить на форму выбор из этого справочника, а у него всегда будет работа только с одним элементом (кстати, взято из Вашего выступления :) ). У Вас есть ВПП в котором как-то зафиксировано это требование и есть реализация. Через пол года заказчик говорит, что "концепция изменилась" и теперь нужен выбор.
Естественно вы просто добавите и все будет ок. Но что если это будет микро функционал, а макро функциональность через всю конфигурацию. В таком случае Вы просто выставите новые требования на доработку, согласуете новый/новые ВПП, зафиксируете и переделаете? Я правильно понимаю?

Тогда чем это отличается от ТЗ, которое точно так же можно сделать в виде корректировки к конкретному блоку, задаче и ТЗ. А еще лучше просто выпустить новую версию к доп соглашению и сделать то же что и у Вас, но в более формализованном виде?

Т.е. главная фишка "гибкого" подхода в сокращении времени до начала процесса реализации.

П.С. из Вашего же примера: если процесс моделирования и согласования требований продлился бы пол года и за это время заказчик осознал необходимость учета не по одному контрагенту, то это потребовало бы изменения ТЗ. В Вашем же случае придется переделывать всю функциональность корректируя ряд ВПП, подключать новых разработчиков в замен выбывшим, которые выполняли эти доработки и т.д. Или я снова не правильно понял концепцию?
45. Сергей (Che) Коцюра (CheBurator) 22.01.15 13:55
(40) понял
Насколько часты споры с заказчиками по вопросу "кто виноват"?
46. Александр Белов (AlexWhite) 22.01.15 15:13
(39) pumbaE,
Не стеба ради, а для обучения.

Стеба ради... Видел ТЗ, объемом 500 листов. Поразило, что это ТЗ имело 5-ю редакцию, составлялось в течение 1 года без пары месяцев. Печаталось в 10 экземплярах каждая редакция, но поразило, что у заказчика находились люди, которые прочитывали каждую редакцию (бумажный вариант), вносили свои правки (разные в каждую редакцию!). Еще больше, правда, меня поразил факт последующей приемки решения (через год разработки, по-моему). При приемке выявлено было более 1200 ошибок, часть из которых (около 200), исполнителю удалось оформить, как доработки за дополнительную плату (1000 исправляли, как ошибки в течение, по-моему, 1/2 года или больше).

Интересно было бы на подобном заказчике продемонстрировать эффективность нашей технологии, у кого есть такой клиент на примете? Организуйте встречу за вознаграждение в 10% от стоимости проекта по факту :-)
47. Александр Белов (AlexWhite) 22.01.15 17:22
(44) Storung,
как будет выглядеть ВПП в случае, например, следующей задачи:
Добавить новый справочник

Поубивал бы за такие ВПП Когда руководитель проектов у нас приводит подобный ВПП, я сильно ругаюсь :-) Если серьезно, когда заказчик пытается формулировать требование подобным образом, получает в ответ вопрос, "какую бизнес-задачу вы хотите решить?".
А вообще, под вашу формулировку, может подойти множество ВПП. Мне вспомнился случай, когда на собеседовании меня попросили решить тестовое задание. Формулировка была примерно такая: "напишите за 1 час простую конфигурацию для учета товара на складе" с некоторыми уточнениями, которые могли служить ВПП (если бы попали в RMS).
Хотим в любой момент увидеть:
1. Пришло за месяц/день) по количеству, сумме
2. Продано за месяц/день) по количеству, сумме
3. Остаток на дату по количеству
На уточняющий вопрос"Хотите видеть, от какого контрагента, сколько товара поступило, какому контрагенту сколько продано?" был получен ответ "Нет, достаточно текстовой информации в документе". Решение было примерно таким, как вы описали (на 1 вид документа больше). Если бы ответ был "Да", то добавился бы еще один справочник (Контрагенты). В мыслях промелькнуло несколько ВПП, примерно такого вида: "Поступило от не важно кому: Барабан 10 шт на сумму 200 руб. Продали не важно кому: Барабан 2 шт на сумму 40 руб. Хочу видеть в отчете: Барабан Поступило 10=200, Продано 2=40 Остаток 8".
Так понятнее отличие ТЗ от ВПП, или еще хотите поабсурдствовать? :-)
Через пол года заказчик говорит, что "концепция изменилась" и теперь нужен выбор.

Да, бывает. В моем выше примере можно даже было предположить, что когда-то учет по Контрагентам понадобится, ВПП, естественно, изменится:
Поступило от не важно кому: станет Поступило от КонстантинаКонстантиновичаКонстантиновского:
Продали не важно кому: станет Продали ИвануФедоровичуКрузинштерну и для отчета появится ВПП.
это будет микро функционал, а макро функциональность

Не микро, а макро, хотели сказать? "Бобер, выдыхай!" :-) Приведите, пожалуйста, пример макро функциональности в УТ.

главная фишка "гибкого" подхода в сокращении времени до начала процесса реализации.

Главная фишка гибкого подхода (нашего, в частности) в его гибкости в отношении ресурсов :-), а именно в наличии возможности динамического формирования и реализации требований. Концепция гибкой методики, по сути, в отсутствии ограничений в исполнительских ресурсах - плати больше, получай больше, когда надо, плати 0, когда не надо. А "быстрый старт" есть и в жестких методиках, в "ТБР", например. В жестких методиках вы действуете в заданных рамках ресурсных ограничений и ограничиваете заказчика при помощи ТЗ. Точнее, заказчик при помощи ТЗ пытается добиться для себя некоторой гарантии, что вы справитесь с поставленными задачами и оговоренный бюджет, а вы, по сути, страхуете себя от изменения требований в сторону превышения ваших возможностей в ресурсах. Хотя, конечно, в SCRUM тоже есть механизм, ограничивающий заказчика в изменениях требований, хотя и на более коротком, чем в классическом проектном подходе, периоде. Хотя, конечно, в части гибкости SCRUM с трудом допускаю, наличие возможности удвоения команды при удвоении объема требований с соответствующей оплатой (одна из причин моего отказа от использования SCRUM :-). Разве что, путем перераспределения ресурсов между проектами, ну да ладно. Надеюсь, разница между жесткой и гибкой методикой стала понятнее? :-)

(45) CheBurator,
Насколько часты споры с заказчиками по вопросу "кто виноват"?

Какой смысл в споре? Нам легче признать себя виновными и исправить, потратив минимум времени, чем терять время на доказательство невиновности, ведь исправить надо в любом случае, вне зависимости от виновности :-)
48. Сергей C (Storung) 22.01.15 18:24
(36) AlexWhite,
Какой смысл в споре? Нам легче признать себя виновными и исправить, потратив минимум времени, чем терять время на доказательство невиновности, ведь исправить надо в любом случае, вне зависимости от виновности :-)


На одном проекте таким образом было "прощено" по одной задаче 40 часов, по другой 20, а в общем около 200 часов. Думаю, что закрыв эти недоразумения в пользу клиента, но не в ущерб разработчиков, проблем бы было меньше, но не все готовы принимать такие радикальные решения :)

Надеюсь, разница между жесткой и гибкой методикой стала понятнее? :-)

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

Приведите, пожалуйста, пример макро функциональности в УТ.

Не буду :) Тут я имел ввиду реализацию функционала по своей сути приближенному к отраслевому решению. Или глобальная переработка существующего функционала под нужды конкретной отрасли. Изменение основополагающего принципа приведет к полному разрушению систему как при гибкой, так и при жесткой методике. Просто в процессе моделирования и составление бизнес-процессов и ТЗ есть вероятность обнаружить или доказать заказчику ошибочность его допущений. Кстати, никто не запрещает сделать "гибкий" механизм, который покроет требования заказчика, но не ляжет при изменении, которые можно предвидеть заранее без ущерба бюджету и срокам. Тут уже вопросы к проектировщику системы.

Про ВПП все-равно не понятно. У нас это называется постановка. Обычно звучит как: реализовать дополнительный разрез ведения учета товаров для нового отчета на основании Остатки на складах. Такие ВПП и правда ставятся, но только на разовые задачи вне проектной деятельности. Тут и правда бюджет ограничен одной задачей и претензии проще решить в пользу клиента.
49. Евген (evg300183) 23.01.15 14:18
Главная фишка гибкого подхода (нашего, в частности) в его гибкости в отношении ресурсов :-), а именно в наличии возможности динамического формирования и реализации требований. Концепция гибкой методики, по сути, в отсутствии ограничений в исполнительских ресурсах - плати больше, получай больше, когда надо, плати 0, когда не надо. А "быстрый старт" есть и в жестких методиках, в "ТБР", например. В жестких методиках вы действуете в заданных рамках ресурсных ограничений и ограничиваете заказчика при помощи ТЗ. Точнее, заказчик при помощи ТЗ пытается добиться для себя некоторой гарантии, что вы справитесь с поставленными задачами и оговоренный бюджет, а вы, по сути, страхуете себя от изменения требований в сторону превышения ваших возможностей в ресурсах. Хотя, конечно, в SCRUM тоже есть механизм, ограничивающий заказчика в изменениях требований, хотя и на более коротком, чем в классическом проектном подходе, периоде. Хотя, конечно, в части гибкости SCRUM с трудом допускаю, наличие возможности удвоения команды при удвоении объема требований с соответствующей оплатой (одна из причин моего отказа от использования SCRUM :-). Разве что, путем перераспределения ресурсов между проектами, ну да ладно. Надеюсь, разница между жесткой и гибкой методикой стала понятнее? :-)
50. Сергей (Che) Коцюра (CheBurator) 23.01.15 14:18
(34) видео это самый последний вариант
Если другие не удастся
Нет ничего лучше чем вживую посмотреть
Многое становится понятныс
51. Сергей (Che) Коцюра (CheBurator) 23.01.15 14:37
(47) как мне кажется например у себя на проете в существенной части вопросов наличие промежуточного звена в виде РП исполнителя было излишним
Вполне бы подошло если бы я напрямую ощался с разработчиками а рп осуществлял бы надзорную функцию по типу чтобы например я не стал бы впихивать программером того что нет в техпроекте

Как вы смотрите на такой вариант?
52. Александр Белов (AlexWhite) 24.01.15 21:10
(48) Storung,
а в общем около 200 часов.
у нас с 2005 года тоже накопилось порядка 580 часов без оплаты от клиентов.
закрыв эти недоразумения в пользу клиента, но не в ущерб разработчиков, проблем бы было меньше, но не все готовы принимать такие радикальные решения

не понятно, что тут радикального?
Не буду :)

Не можете :-) Очень сложно, придумать - успели написать УТ и выяснили, что надо было БП написать? Или товар стал контрагентами в упаковках торговать? :-)
реализовать дополнительный разрез ведения учета товаров для нового отчета на основании Остатки на складах

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

у нас рабочие группы динамические - больше требований, больше участников.
53. Александр Белов (AlexWhite) 24.01.15 23:13
(49) evg300183, где-то спрятан вопрос или конкурс на лучший пересказ? :-)
(51) CheBurator,
если бы я напрямую общался с разработчиками а рп осуществлял бы надзорную функцию по типу чтобы например я не стал бы впихивать программером того что нет в техпроекте

В нашей технологии заказчик общается с РП или управляющим (помощником управляющего). Чтобы общаться с разработчиками, над быть РП. Опыт постановки задач программистами вместо заказчика оказался отрицательным.
54. Богатырев Артур (Богатырев Артур) 26.01.15 10:34
(42) AlexWhite, Рискну таки с вами не согласится в ряде пунктиков. Тут выше писали что "Ваше ВПП это отдельные части ТЗ, разница лишь в том, что в ТЗ описано как они связаны между собой", хотя вы уверяете в обратном. Скажем, вы вот упоминали выше, что таки да, участвуете в проектах с тендером (с определенным бюджетом), производите встречи с заказчиком и т.п. - а это как известно первые ступеньки, без которых нереально составление вообще какого либо плана (ТЗ, бумажки, ВПП, плана "Барбаросса" - нужное подчеркнуть).
Лично мое мнение, что вы на самом деле составляете ТЗ, а в какой форме и под каким именем вы это составляете - это частности, хоть в картинках, хоть в комиксах, хоть в виде мега-ТЗ с красивыми расчетами, хоть в виде некоего демо-примера контрольного (ВПП) и интерактивного. В любом случае вы составляете некую вещь (документ, образец), который служит вам техническим руководством к действию.
Без сомнения, ваше важное отличие и достижение от традиционного ТЗ в том, что вы это делаете в оригинальной форме (применяя итерации, декомпозиции, новые формы общения с заказчиком и сдачи ему частей и доработок и т.п.). Правда какой то революции я все же не вижу. У вас - весьма интересный и оригинальный метод составления технической документации к проекту. Вы реально хорошо экономите на составлении огромного мануала - традиционного ТЗ, который и верно устаревает в процессе. Я бы назвал ваш метод - "динамический итерационный метод составления приближенных ТЗ с применением глубокой декомпозиции и методов эмпирического анализа". Красиво? :) Почти шутка. На самом деле невооруженным взглядом видно, что у вас проделана большая работа по устранению традиционных недостатков работы с ТЗ, тем более, что ряд ваших идей весьма близко похожи на мои мысли.
Я вот с вами согласен, что нельзя делать ТЗ жутко формализованным - это абсурд. С другой стороны, я согласен с позицией, что заказчик на самом деле может смутно представлять на самом деле что ему нужно. Тут большая трудность пояснить заказчику, что его некое желание потребует нехилых усилий (т.е. и средств заказчика), или вообще понять точно что он хочет. Правда, как я смотрю по вашим ответам, у вас очень большой упор на начальную беседу и выпытавание у заказчика точной информации. Но это опять таки хороший тон в составлении хороших ТЗ.
Вы упомянули, что с 2005 года накопили 580 часов без оплаты от заказчика. Даже по самым мега-скромным прикидкам (1000 рублей час) - это более полумиллиона неполученного дохода... А вы так легко "сдаете" все спорные ситуации? Это точно зря. Естественно придется эти спорные ситуации исправлять, но эти ситуации возможно частично оплатил бы заказчик. Как бы это банально и грубо не звучало, но коммерческие разработки заинтересованы в бОльшем оплаченном обьеме.
В остальном точно искренне желаю удачи в развитии своего подхода. А идея с сертификацией - очень умно. Вам бы еще книжку написать и издать на эту тему... :)
55. Сергей C (Storung) 26.01.15 17:04
(52) AlexWhite,
не понятно, что тут радикального?
то что большинство компаний называют "солидарной ответственностью" и перекладывают свою убытки на исполнителя, ведь именно он не смог донести до руководства часть информации о возможных потерях.
Не можете :-) Очень сложно, придумать - успели написать УТ и выяснили, что надо было БП написать? Или товар стал контрагентами в упаковках торговать? :-)

Кстати, вот именно Ваш пример и натолкнул меня на одно воспоминание. Пришел к нам клиент с бухгалтерией с дописанным блоком зарплаты. Ушло на это несколько сотен часов, а функционал не дотягивал даже до КА. А ведь начиналось все тоже с простенького механизма на 40 часов для учета внештатников. Если бы был изучен весь фронт работ вряд ли было бы выбрано такое решение. Я уже не буду описывать процессе перехода на КА этого клиента. Как ВПП и гибкий подход тут помогли бы?
"хотим знать, сколько товара от какого поставщика на складе" - и вот тут будет сформулирован ВПП
Хотим знать - это уже ВПП или что-то нужно еще?
у нас рабочие группы динамические - больше требований, больше участников.
Так можно сказать про любую фирму франчайзи - они для того и есть, чтобы балансировать нагрузку между проектами. Мне вот не понятно как скоординировать работу 4-6 разработчиков над одним проектом в рамках одного функционального блока, если у нас даже в хранилище ломают функционал друг друга. Если Ваши РП могут все это координировать, тогда Вам однозначно нужно написать статью именно об этом: согласование доработок, контроль версий, тестирование объединенных блоков и т.д. Я видел, что это у Вас есть, но Вы ограничились лишь общими фразами, а это не менее интересная тема и Вам есть что рассказать.
56. Сергей (Che) Коцюра (CheBurator) 26.01.15 18:25
(54) 580 неоплаченных счетов с 2005 г.
Прикинем: 10 лет ( с 2005 по 2014), возьмем 245 рабочих дней в году, = 245дней*10лет*8часвовдень = 19600 часов
580 неоплаченных часов составляют чуть менее 3%, с учетом ч то работает не один человек, а десятка два наверное, то колво неоплаченной работы составляет ~ 0.2% Я считаю что это выдающийся результат, особенно в условиях нечеткой постановки задач.
57. Сергей (Che) Коцюра (CheBurator) 26.01.15 18:27
(55)
если у нас даже в хранилище ломают функционал друг друга.

тут есть паралельные ветки про гитхабы и прочие инструменты для командной работы, интересно...
58. Богатырев Артур (Богатырев Артур) 27.01.15 09:33
(56) CheBurator, минутку, уважаемый, речь идет не об часах работы вообще. А об оплаченных "часах работы подрядчика". Всем известно, что франчайзи (подрядчик) делает некую работу и выставляет счет заказчику, где указано, что на такую то доработку потрачено 100 часов разработки (я грубо утрирую). Эта сумма часов значительно меньше общего числа рабочих часов сотрудников подрядчика.
И кстати, если работает более 1 человека, это еще катастрофичнее, т.к. 1 час выставленный заказчику скрывает 2-3-4 часа работы разработчиков.
Так что 580 часов это не так уж мало. Не скажу что это очень много впрочем тоже. Вопрос в том скорее, что подход таков у автора статьи - не вступать в споры, а исправлять за свой счет. Это неправильно, нужно гибче подходить, а то заказчик может тупо оборзеть.
59. Сергей (Che) Коцюра (CheBurator) 27.01.15 13:04
(58) Главное спокойствие
Я например выступаю в основном заказчиком сейчас
Регулярно выступаю и исполнителем
Залог успешной работы это компромиссы и маленькие бонусы друг другу
Ничто так не выбешивает меня как заказчика как формальный подход к работе
Когда вроде все сделано но лучше бы так не делали
Поэтому гибкий подход Белова с постоянным уточнением требований это есть хорошо
Конечно только тогда когда у тебя нет своих программистовразработчиков
Своими сделать выходит от двух до четырех раз дешевле
Имхо конечно
60. Александр Белов (AlexWhite) 27.01.15 14:16
(54) Богатырев Артур,
В любом случае вы составляете некую вещь (документ, образец), который служит вам техническим руководством к действию.

Ошибаетесь, Артур. Да, случается, что мы разрабатываем ТЗ, если это требуется в тендере или в другой "клинике" :-), но стараемся на него потратить самый минимум времени и это лишь формальный документ, вплоть до Ctrl^C+Ctrl^V и замены заголовка, либо предоставленное заказчиком в условиях к тендеру. Сомневаюсь, что когда-то мы задействуем ТЗ в качестве технического руководства к действию. Максимум, где востребован документ, похожий на ТЗ, это в части интеграционных проектов, где нам приходится договариваться именно о технических деталях взаимодействия с другими ИС и их производителями (Например, "Справочник.Контрагенты.Код <-> Contra.ID (String 20)").
вы это делаете в оригинальной форме

Нет, для нас важнее содержание проекта. Точнее описано в другом докладе http://infostart.ru/public/318229/ а именно:
  • •Люди и взаимодействие важнее процессов и инструментов
  • •Работающий продукт важнее исчерпывающей документации
  • •Сотрудничество с заказчиком важнее согласования условий контракта
  • •Готовность к изменениям важнее следования первоначальному плану
И для меня странно, чего, вдруг, обсуждение технологии началось в статье про опыт сертификации СМК? :-)
большой упор на начальную беседу и выпытавание у заказчика точной информации

Информация информации - рознь. Да, на начальном этапе взаимодействия стараюсь точнее выявить СУТЬ потребностей, но потратить на это минимум времени. Гораздо важнее, понять состав ключевых пользователей заказчика и организовать взаимодействие с ними через RMS.
это более полумиллиона неполученного дохода...

580 часов без оплаты - это чуть больше 0,6% от фактически выполненных работ за тот же период, какой смысл за них бодаться, это, ведь, множество заказчиков, кто-то остался должен 20 минут, кто-то несколько десятков часов? :-)
61. Александр Белов (AlexWhite) 27.01.15 16:01
(55) Storung,
называют "солидарной ответственностью" и перекладывают свою убытки на исполнителя
По-моему, в формулировке противоречие. Как может быть солидарной ответственность, переложенная на одну сторону?
Но, не важно. Использую простой подход к себе и другим - ошибки исправляю за свой счет, доработки за счет заказчика, в спорных ситуациях, уступлю. Для меня, результат дороже денег, чувствуете отличие от "договор дороже денег"? ТЗ, с моей точки зрения, это "договор" с попыткой "объять необъятное" и "договориться о неизвестном".
Как ВПП и гибкий подход тут помогли бы?

Элементарно. Наличие простой формулировки, вида "необходимо автоматически рассчитать отпускные, больничный" на самом первом этапе уберегли бы клиента от нескольких сотен часов доработок в пользу ЗУП с настройкой взаимодействия с их БП или КА + перенос данных из существующей БП.
Работающий продукт важнее исчерпывающей документации

Но в вашем примере, похоже, клиент, попал на ТЗ и сотни часов доработок :-)
Хотим знать - это уже ВПП или что-то нужно еще?

В смысле? Вопрос про 2 слова "хотим"+"знать"? Или вы про фразу
хотим знать, сколько товара от какого поставщика на складе
спрашиваете?
Если про фразу, то эта формулировка является, лишь, требованием заказчика. Чтобы появился ВПП (повторю, Воспроизводимый Пользовательский Пример), должно появиться описание последовательности действий пользователя и ожидаемого результата от этих действий. Хотя указанная формулировка будет, скорее всего, решена без ВПП, так как для понимания и реализации этого требования достаточно здравого смысла. Вы имеете право, хранить молчание, все, что вы НЕ скажете, будет решено в суде в пределах здравого смысла :-)
если у нас даже в хранилище ломают функционал друг друга

Все ошибаются. Ошибочно полагать, что ошибок можно избежать, если внедрить только хранилище.
Мне вот не понятно как скоординировать работу 4-6 разработчиков над одним проектом

Со слов знакомого коллеги из другой фирмы, у них в одном проекте (в одном хранилище) трудится около 40 специалистов, из которых около 10 человек выполняют роль администраторов хранилища. У нас с одним проектом параллельно работают 10-20 специалистов, но обходимся без выделенных админов. Внедрение хранилища вне зависимости от его вида - это лишь малая часть задач, которые надо решить при организации успешной коллективной разработки программного обеспечения. Опишу, как у нас они решены, вероятно, в других статьях, позже :-)
(56) CheBurator, слишком общие допущения и расчет получился ошибочный, хотя всего в 3 раза оптимистичнее фактического
это чуть больше 0,6%
в (60) :-)
(58) Богатырев Артур,
580 часов это не так уж мало
- менее 0,65% - достаточно мало, чтобы отказаться от заморочек по этому поводу :-) Причем, основной долг образовался в начале развития технологии (в 2005, в основном), многих ошибок прошлого удается избегать в настоящем за счет внедрения и сертификации СМК, в том числе.
62. Александр Белов (AlexWhite) 27.01.15 16:35
(59) CheBurator,
Своими сделать выходит от двух до четырех раз дешевле
достаточно спорное утверждение. Сколько человек, какой квалификации надо взять в штат, чтобы написать WMS за 90 дней, от 30 до 60 из которых уже потрачено на тех.проект/ТЗ? Выполнима ли эта задача? Вспомни концептуальную модель усилий Барри Боэма http://infostart.ru/public/318707/ , хорошо объясняющую поговорку "даже самую простую задачу можно сделать невыполнимой, если провести достаточное количество совещаний" :-)
Могу рекомендовать, кстати, всем книжечку "Управление программными проектами. Практическое руководство по разработке успешного программного обеспечения", автор Марри Кантор.
63. Сергей (Che) Коцюра (CheBurator) 28.01.15 00:15
(62) смотря какая ВМС. Если гибконастраиваемая, адаптивная, с последующим минимальным кодингом и большинством параметрических настроек - то и за 90 дней весьма проблематично если не невозможно. Если же ВМС, ориентированную на конкретный склад или область деятельности заказчика - то не то что вполне реально, а вполне осуществимо.

но это я отвлекся ;-)

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

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

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

как-то так.
может, конечно, все неправильно вижу.
64. Сергей (Che) Коцюра (CheBurator) 28.01.15 00:20
(56) > CheBurator, слишком общие допущения и расчет получился ошибочный, хотя всего в 3 раза оптимистичнее фактического
/
ну, какие исходные данные выдали - то и прикинул лаптем к носу.
а то что получилось у меня в 3 раза оптимистичнее чем есть на самом деле - это значит что у вас суммарная часовая выработка за указанны йпериод в 3 раза меньше или количество постоянно работающих меньше чем я предположил (или другие неучтенные данные мною)
65. Dim Dragonim (Dragonim) 28.01.15 20:36
"Смешались в кучу кони, люди"
1. Обсуждают систему работу исполнителя с заказчиком в теме про стандартизацию и попытку получения ISO 9001
2. Идёт постоянное перескакивание с понятия "доработка существующего решения" на "создание нового решения с нуля" на "объединение существующих решений" и обратно.
3. Я писал выше, напишу и тут. Я не понимал в чём новшество вашего подхода и, в частности, ВПП в доработке существующего решения, т.к. именно так работают практически все кого я знаю, а многие выполняют задачи по отрывкам мыслей из разговоров и заказчики остаются довольными. Я не понимаю как вы собираетесь использовать ВПП в проекте создаваемом с нуля, т.к. будь у вас хоть 1000 ВПП от всех заинтересованных лиц, пока не будет чёткого понимания (лучше оформленного в письменной форме) основы и логики работы всей системы как единого целого, вы не сможете выдать адекватный результат.
4. Я всегда боялся руководителей которые говорят "я работаю для фана/интереса/результата/добавь_своё, а прибыли у меня на 2/3/4/. ./N месте". Для меня это значит, что такой руководитель может в один прекрасный момент встать и сказать, "я устал, пойду позанимаюсь другим делом, там интересней", или выполнить работу, а на оплату забить, потому что ему не охота бодаться, ведь он выполнял работу ради работы, или он врёт мне в лицо и прибыль у него на первом месте, а весь разговор пустое сотрясание воздуха. Лично мне страшно работать на такого человека.
66. Александр Белов (AlexWhite) 29.01.15 11:07
(63) CheBurator,
Конечно, своего фикса надо пинать, руководить и прочее. Но все равно будет дешевле.

Свой дороже! Но стоимость - не первый критерий при выборе "свой/чужой". Заказчик платит за "своего" дороже, так как оплачивает ему за работу, за простои и, даже, за наличие физической возможности, пнуть при случае :-)
"Свой" нормальный программист работает близко к пределу своих возможностей. Поэтому, удвоение оплаты своему программисту влияет только на увеличение его лояльности к вашей фирме, а объем работ остается без изменений. Если вы заплатили своему прогу в 2 раза больше и результат удвоился, это означает, что этот прог прежде сочковал. Чтобы найти второго добросовестного и квалифицированного программиста, потребуется время на поиск и испытание (1-3 месяца), но 2 программиста в штате не программистской организации потеряют в части производительности. То есть, при удвоении платы выработка возрастет, но, лишь в 1,5 раза в самом оптимистическом случае, а в реальности, скорее всего, останется на прежнем уровне или вообще упадет (зависит от количества совещаний).
Кроме того, "своему" оплата производится от календаря (оклад). Рано или поздно, но среди интересов "своего" приоритетным становится "меньше поработать, но сохраненить стабильность" и, как следствие - "работает, не трожь!", так как процесс программирования тесно сопряжен с процессом создания ошибок, за которые будут ругать и могут пнуть, когда работодателю надоест платить за работу по исправлению ошибок.
Услуги внешнего подрядчика будут дороже, если на подрядчика наехали, "оцените, подпишитесь кровью!". Конечно, кому охота подставляться - тут и ТЗ появится за плату и к сумме будет добавлено 2 - 3 цены для страховки от рисков.
В нашей технологии, стоимость будет сопоставима со стоимостью "своего" за сопоставимый результат, так как ТЗ не нужно, а сотрудничество строго в рамках технологии позволяет обойти риски и гарантирует получение требуемой функциональности, в ожидаемые сроки, за приемлемую плату. Однако, наши возможности выше, чем у "своего" - удвоение требований с удвоением оплаты приводит к удвоению результата! А чтобы мои слова получили вес в разговоре с потенциальным клиентов, была внедрена и сертифицирована СМК. До ее внедрения, у меня был только 1 способ, доказать эффективность технологии - предоставить возможность, воспользоваться ею :-)
67. Александр Белов (AlexWhite) 29.01.15 14:04
(65) Dragonim,
вы не сможете выдать адекватный результат.
оставьте подобные утверждения для себя :-)
Мы уже сделали - предоставили заказчику требуемую функциональность, в ожидаемые сроки, за приемлемую плату. Например, разработали и внедрили WMS за 90 дней с нуля, без ТЗ, уложившись в ожидания заказчика к стоимости, сформированные, как 1/2 оценки стоимости проекта внедрения на основе "готового" решения.
4. Я всегда боялся руководителей которые говорят "я работаю для фана/интереса/результата/добавь_своё, а прибыли у меня на 2/3/4/. ./N месте".

Извратили формулировку, но, значит, продолжайте меня бояться :-)
Для меня действительно результат дороже денег и вопрос приемлемой стоимости стоит на третьем месте в процессе принятия решений о покупке/продаже товаров/работ/услуг.
Много раз сам выступал в роли заказчика и, однажды, искал подрядчика для создания сайта. С одним из потенциальных подрядчиков провели примерно 2-часовое скайп-совещание, в течение которого я рассказал и продемонстрировал свои потребности. После окончания совещания, получил от них такое предложение, "давайте, мы разработаем вам ТЗ за 1 месяц и 0,5 млн.руб.". Естественно, сотрудничество не состоялось, так как за 2 часа моего рассказа можно было понять, что 1) "нам кузнец не нужен ТЗ не нужно 2) тем более, за 1 месяц - и не важно, 3) что они запросили за это 0,5 млн.руб, мне ТЗ за 1 месяц не нужно даже бесплатно!
А, вот, нужно ли мне ТЗ за неделю? Вопрос открыт, так как опыт подсказывает, не нужно, но любопытство могло подстегнуть, "фиг с ними - с перьями, но я хочу это видеть!" :-) и тогда, конечно, я бы начал анализировать приемлемость стоимости - 0.5 млн/неделю - многовато будет, 10 тыс.руб в неделю - "О! Это мой размерчик!" :-)
Когда нахожусь в роли исполнителя - какой смысл, мне беспокоиться о прибыли, когда я уверен, что при работе строго по технологии интересы всех участников будут удовлетворены?
Заказчик: получит требуемую функциональность, в ожидаемые сроки, за приемлемую плату.
Разработчик: решит интересную задачу за согласованное вознаграждение (+ к авторитету, карме и т.д.).
Руководитель проектов: успешно завершит очередной проект, увеличив число осчастливленных заказчиков еще на 1, получив всеобщее признание и достойное вознаграждение за руководство.
Руководители организации: получат удовлетворение от очередной коллективной победы, всеобщее признание и одобрение (материальное в том числе).
Владелец бизнеса: получит свой процент рентабельности.
перечень удовлетворенных ролей и интересов можно еще продолжить, но не важно, мысли и чувства должны быть свободны от беспокойства по поводу денег, когда речь идет о результате, достижимом при соблюдении технологии.
встать и сказать, "я устал, пойду позанимаюсь другим делом, там интересней"

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

Бодаться за оплату сделанного - вне сферы моих интересов. Отсутствие оплаты за сделанное для меня означает, что, вероятно, это случилось вследствие допущенного отклонения от технологии работы и урок на будущее, чтобы избежать отклонения или минимизировать его влияние, когда сотрудничество без подобного отклонения будет не возможно. Если требуемая функциональность, в ожидаемые сроки, за приемлемую стоимость была предоставлена, мои обязательства выполнены, интерес к достижению результата удовлетворен, совесть чиста. Заказчик оставил полученное без оплаты, значит, он не выполнил свои обязательства - сам пусть с этим живет, но дальше без нас - давайдосвидания! :-)
или он врёт мне в лицо и прибыль у него на первом месте

...или финансовый критерий для него действительно на третьем месте и его технология, опытом сертификации СМК которой по ISO 9001:2008 он поделился, действительно позволяет получать требуемую функциональность, в ожидаемые сроки за приемлемую плату. Я правильно закончил начатую вами фразу? :-)
Вот корень вашей проблемы при попытке понять ближнего своего и воспользоваться чужим опытом для своей пользы! Вместо "доверяй, но проверяй", вы используете "ни кому верить нельзя, даже себе" :-), поэтому, не можете понять, как большие проекты могут быть решены без ТЗ :-)
Мне жить проще: театр начинается с вешалки сотрудничество начинается с доверия - Хотите автоматизации? Их есть у меня - гарантирую требуемую функциональность, в ожидаемые сроки, за приемлемую плату - пробуйте! Для некоторых добавляю, "если результат работы 2 недель не устроит, сможете прекратить сотрудничество без финансовых потерь с вашей стороны".
Чего и вам желаю! :-)
68. Богатырев Артур (Богатырев Артур) 30.01.15 14:02
(66) AlexWhite, c некоторым запозданием, но отвечу на ряд ваших ответов (пардон за каламбур :) )
Постараюсь быть достаточно кратким.
Вы пишете, что "не составляете ТЗ", но повторюсь, вы на практике его составляете. Просто "ваше" ТЗ не составляется в виде одного или даже группы документов. Вы можете не соглашаться со мной, но ваше взаимодействие с заказчиками оставляет следы? Да, оставляет (не устно же вы общаетесь?). Так вот, любые следы - от видео до простых писем по электронке, как ни странно, это тоже ТЗ (вернее, куски его). Не формализованные часто, но ТЗ. Возможно, у меня неверная терминология, но для меня ТЗ - это все, что описывает пожелания заказчика, процесс работы программы, ответы на вопросы разработчика и т.п. Просто напросто НЕЛЬЗЯ работать без документальных следов, пусть даже эти следы - только электронные.
Про то, что якобы "свои" программисты мол "работает близко к пределу своих возможностей. Поэтому, удвоение оплаты своему программисту влияет только на увеличение его лояльности к вашей фирме, а объем работ остается без изменений." Прошу прощения, искренне прошу, но это реклама сторонних подрядчиков... :) Я лично всегда считал и считаю что "свои" сотрудники выгоднее подрядчиков.
Во-первых, о занятости. Если организация затеяла проект и привлекла свой Ай-Ти отдел, это значит, что она ДОЛЖНА иметь ресурсы в виде наличия люфта времени у своих Ай-Ти для нового проекта. Если не имеет - это проблема руководства, что приняло неверное решение.
И кстати, идея найти нового программера и ввести его в курс дела - вы пишите 3 месяца. Супер. Вы не уточняете, что поиск хорошего подрядчика, и введение его в курс дела, это, пардонте, тоже не сутки и не двое. :)
Далее, очень старая аксиома, что работающий в штате специалист заведомо лучше знает специфику работы предприятия, включая "не совсем официальную" - пардонте, но такие штуки как завязка процессов на ключевых людей в организации, или знание, что при 10 бухгалтерах у нас 8 сачки - никто не отменял. Значит такой сотрудник НЕ будет тратить время (и деньги компании), чтобы "вьехать" в процессы, в отличии от подрядчиков.
Также общеизвестно, что ЛЮБОЙ "свой" сотрудник стоит дешевле подрядчика. При этом если нашего сотрудника мотивировать денежно, то добавится охота и вечером и в выходные работать.
Проблему оплату по окладу вообще решить элементарно - введя систему бонусов и мелких премий.
В остальном все плюсы вашего подхода я сугубо разделяю, разве только третьестепенную заинтересованность в фин-результате не разделяю. Финрезультат - 1-й из 2-х основных стимулов. 2-м является собственно "интерес"
Dragonim; CheBurator; +2 Ответить 1
69. Александр Белов (AlexWhite) 30.01.15 17:28
(68) Богатырев Артур,
вы на практике его составляете.

Нет https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0­%BA%D0%BE%D0%B5_%D0%B7%D0%B0%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5 - такой документ в нашей технологии отсутствует.
Да, оставляет (не устно же вы общаетесь?)

Да, оставляет, даже, если общаемся устно! Но это другие следы, достаточно далекие от понятия "техническое задание". Эти следы являются сообщениями или требованиями, для управления которыми создана целая "Система управления требованиями" (RMS).
Документ, похожий на ТЗ, может появиться в интеграционном проекте, в части согласования протоколов взаимодействия с интегрируемой системой. Но это, скорее, техническая спецификация, чем техническое задание.
Вы не уточняете, что поиск хорошего подрядчика, и введение его в курс дела, это, пардонте, тоже не сутки и не двое. :)

Зачем искать, когда можно выбрать нас, в качестве подрядчика, заключить договор за 1-2 дня, получить первый результат в течение 1-2 недель, готовое решение в течение 3-12 недель? :-)
что работающий в штате специалист заведомо лучше знает специфику работы предприятия

Лучше/хуже - понятия относительные. В проектной деятельности есть множество процессов, которые могут выполняться только штатными специалистами, но есть много процессов, которые можно выполнить силами внешнего подрядчика.
В нашей технологии есть место каждому специалисту, и штатному, и удаленному, и руководителю проекта, и конечному бизнес-пользователю. Работающий в штате специалист, само собой, лучше нас разбирается, когда в его базе максимальная нагрузка, когда можно "пнуть" народ, сделать архив, подгрузить изменения - отлично! Пусть возьмет на себя эту часть ответственности - забирает готовое из RMS, проверяет работоспособность на своем тестовом стенде, демонстрирует своим ключевым пользователям на тестовом стенде, сообщает нам о просочившихся ошибках, планирует и выполняет внедрение в рабочую базу. Но возможности штатного специалиста ограничены возможностями одного человека в части компетенций и времени, в сравнениями с возможностями команды, формирующейся динамически. Будете оспаривать?
Кроме того, владелец бизнеса, руководитель предприятия, руководитель отдела продаж, главный бухгалтер, бухгалтер, менеджер по продажам - каждый квалифицированный бизнес-пользователь на своем рабочем месте разбираются в специфике своей работы лучше собственного программиста и лучше нас, поэтому кто-то из этих в нашей системе будет зарегистрирован в качестве ключевого пользователя и будет являться источником требований (функциональным заказчиком или выступать в другой роли) и конечным получателем решений. Видел, однажды, как прог 1С стал финансовым директором, написав финансовую нетленку для своей конторы, специфику которой, как вы говорите, он знал вдоль и поперек - печальное зрелище в части его нетленки и, увы, печальная участь постигла компанию.
что ЛЮБОЙ "свой" сотрудник стоит дешевле подрядчика

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

Да, возможно еще и ночью, и грабли кое-куда привязать, пока не сгорит на работе. Складно сказка сказывается, да не скоро дело делается :-)
Финрезультат - 1-й из 2-х основных стимулов

А какие 2 стимула имеете в виду? Если у вас на первом месте денежный интерес, какой смысл, заниматься программированием, чтобы стать хацкером и ограбить банк? :-)
70. Wooster 31.01.15 22:22
Александр, интересует вопрос "приемлемой платы", которую вы предлагаете обозначить заказчику.

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

Встал вопрос о "приемлемой плате".

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

За одинаковую "требуемую функциональность" и "ожидаемый срок" разные заказчики могут предложить суммы от нуля до бесконечности. Кто-то предложит 500 рублей, кто-то 100000 (из них 20000 в конверте).

В это же время у вас:

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

- был опыт реализации подобной функциональности, но в устаревшей конфигурации и требуется время проанализировать, сколько ресурсов займет реализация функциональности в текущей конфигурации;

- не было опыта реализации подобной функциональности.

В общем, в ряде случаев вам сразу будет неизвестна "ваша" оценка функциональности (надо будет потратить время, оценить).

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

Если "приемлемой плата" больше, чем вы ожидаете, предлагаете ли заказчику сделать дешевле или просто радуетесь и работаете ?

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

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



71. Александр Белов (AlexWhite) 01.02.15 11:08
(70) Wooster,
В общем, в ряде случаев вам сразу будет неизвестна "ваша" оценка функциональности (надо будет потратить время, оценить).

Больше скажу, оценка всегда не известна. Варианты устранения неопределенности:
1. Оценить (мы или заказчик) без решения.
2. Решить, оценив по факту (наш способ).
Если при передаче заказчик высказал отклонения в отношении стоимости полученного в п.2 решения, вероятнее всего, решение было сделано с отклонением от технологии. Корректирующие действия проводятся в зависимости от выявленной причины.
Не мешает ли запрос "приемлемой платы" финансовому планированию в компании ? Вы же планируете, наверное, сумму, которую компании требуется заработать за месяц

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