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

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

Самый забавный проект я вел не в 1С. Тогда и 1С то еще не было.
А для одной очень серьезной организации, название которой вам не скажу, но глава ее ныне МО РФ.
Надо было записать в БД тесты группы из 10-15 человек.
Поскольку группа небольшая - ключ сделали ФИО, казалось невероятно что среди 15 человек будут такие дубли.
У первого же оттестировавшегося было четыре Атабека Атабаевича Атабаева....
Доделывали в поезде Санкт-Петербург - Москва.
Хорошо еще что "Сапсанов" тогда не было, а ноутбуки были и времени хватило

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

А уточнить и спросить у разработчиков-внедренцев времени как всегда не хватило.

1. Самая непростая проблема - привить интерес к проекту людям, которые в нём не заинтересованы. Заказчик, как правило, руководитель, а работать с проектом будут подчиненные. Они боятся, что новый виток автоматизации не упростит им жизнь, а добавит работы. Так было с внедрением CRM. Исполнитель у заказчикам предпочитал известную WEB-платформу, а нам поставили задачу пересадить на 1С:УТ и обучить вести там коммерческие предложения, проекты, счета, заказы и оплаты. Перенесли данные, расширили обмен с кастомной УПП. Что в итоге? Подчиненный так и бьёт заказы в CRM, его босс его защищает, а начальник IT и ГД настаивают на решении 1С. Надеюсь текущее внедрение ERP поможет им пересесть на 1С.
Таких примеров много и все они разные.
2. Самая интересная проблема на внедрении. Такие проблемы чаще всего находятся в специфике работы компании и попытке применить их на типовом решении. Не могу выделить конкретную задачу, но в целом на опыте самое интересное - это изучение конфигурации, которую выбрал заказчик для перехода, а ты о работе с ней до этого только мечтал :)
3. Ещё одна одновременно и сложная и интересная задача на внедрении - найти консультанта и/или программиста на такой проект. И что бы не компания, а ИП или физлицо, ведь бюджет не резиновый. Переписки, согласования, ТЗ - ценнейший опыт, за который потом не стыдно ;)

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

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

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

Где-то через неделю я написал заявление на увольнение: перешел из франча на фикси.
Почистил свой комп от всякого хлама, включая и наработки по описанному внедрению. А еще через неделю они позвонили снова: во время грозы у них сгорел RAID с новой базой, старой базой, с их бэкапапми (привет админу) и вообще всем, что как-то было с этим связано. Зато остался шкаф с распечатками. Словом, неделька перед увольнением выдалась веселой)

Главный вывод, который я сделал: внедрение - это всегда насилие над клиентом. Уж очень часто работников клиента приходится заставлять переходить на новые системы.
Ну и еще можно сказать, что результат внедрения - это не перенос данных или разработка, т. е. не работоспособность конфигурации самой по себе, а работоспособность всей системы "БД+пользователи"

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

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

Ситуация на проекте.

Ресурсов в компании нет;
Компетенций в компании нет;
Сроки сжатые
Подрядчика можно взять только в рамка тендера
Отказаться от проекта нельзя.

Так и живем.

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

Не учавствовал в проектах.

Поработал как то в торговой сети (70 магазинов, центральная база 2 ТБ).
Самое сложное это вовремя провести накат релиза (платформа часто требует ТИИ).
Задача давно лежала на поверхности (обновление конфигурации средствами СУБД).
Решение:
1. Получаем структуру метаданных до изменения конфигурации.
2. Получаем структуру метаданных после изменения конфигурации.
3. Отключаем триггеры в таблицах с отличиями.
4. Переименовываем таблицы с данными.
5. Создаем таблицы без данных.
6. Изменяем таблицы с данными после применения изменений.

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

В моей практике самая острая проблема была - "Эффективные менеджеры".

Особенно в экономической сфере.

Самое сложное - это сделать так, чтобы описанные, утвержденные бизнес-процессы соответствовали реальной работе. Часто автоматизируется хаос, поэтому Scrum стал популярен. Много неизвестных, нестабильности требований. Большая часть проблем проектов автоматизации лежат вне рамок автоматизации. Нужен новый тренд: комбинация консалтинговая компания (не связанных никак с 1с) + интеграторы 1с. Нужен объективный синтез, а не "разведение" на бабло.

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

Инициатива от собственника потому что накипело и нужен контроль.
Суть проекта - дописать и внедрить систему для детального учёта производственного процесса. Контроль и автоматические расчеты статистики.
Проблема - банальное нежелание некоторых сотрудников участвовать в процессе, потому что они понимают что в итоге у них будет больше свободного времени :) и их нагрузят чем-то ещё. И ключевая проблема - тотальное недоверие собственника к 1с.
Верхи не хотят , низы не могут или наоборот. А почему пошли по этому пути - ну все же идут, значит так надо.

Самая острая проблема в проекте внедрения на мой взгляд это отсутствие компетенций у руководителя проекта. Поэтому живо гоните мне обучение :D

Был клиент: розница, внедряли учёт.

Только вот расположен в районе Егорьевского проезда.
Естественно поехал на электричке. Билет до ДЕПО КУР (железнодорожники называют Люблино сортировочное, а севернее Люблино дачное-для пассажира Люблино, но не метро).
Внедрение недели на 3. На 10 дней билет взял в Бутово (так как ещё 46 налоговая на Трикотажной, клиент в Калитниках, ещё случайности по мелочи) и с ним проблем не было.
А с разовыми интереснее: спрашивают что за птицы? Объяснял что никакой птицы не видел. Внедрял учёт на птицефабрике. Что? только потом выяснилось.

Билет был нужен, так как пересаживался на Каланчёвке, тогда автоматов не было и можно было потерять времени (на Курском турникетов ещё не было, поставили их очень поздно; стояли они только в горьковских тупиках).

Самое сложное было дописать код по мелочи,а я код не знал

Добрый день.

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

Как обычно всюду вмешивается политика. До 2014 г у нас в компании пользовались в качестве программы документооборота docsvision. Был он немного глючный и люди плевались иногда, но работали. Возник вопрос исправления ошибок и доработки функционала и ребята из docsvision то ли цену заломили, то ли просто поругались с нашим директором it. В итоге решено было устроить тендер на выбор новой программы документооборота. И выиграла тендер одна известная на российском рынке компания(тоже в названии есть цифра 1), которая пообещала, что выполнит все требования и за самую меньшую цену.
И начался небольшой ад. Все сроки были превышены и разработка ведется по сути до сих пор.
Периодические накаты обновлений вообще не тестировались и ошибки ложились на пользователей. Согласование документов постоянно зависало (и до сих пор так). Частенько после наката обнаруживались ошибки, которые уже были ранее исправлены.
Как итог - техподдержка ит и программисты 1с проходили курсы разработки в этой конторе и половину рабочего времени тратили не на 1с, а на уникальную программу документооборота. За пару лет отдел ит обновился на 90%. Опыт с этой программой нигде больше не пригодится.
Так вот проблема, что от той конторы никуда не уйти, потому что программу это разрабатывают только они, считай монополисты. Мы оказались в ситуации, когда ежики колются но продолжают делать дело...
Оказалось, что контора та не собиралась нас ктдать на тендере, а это у них так всегда - реальные сроки и стоимость занижена минимум в 3 раза. И ничему их жизнь не учит. Казалось бы, умножь расчет на 3. Но нет. Все новые задачи также неадекватно оценивают , а потом клянчат деньги и жалуются что сработали в минус . И так каждый раз. У самих тоже рук проектов и разработчики меняются как перчатки. Конфа на веб интерфейсе и смартах(скриптах) на уникальном языке. Сложность вхождения феерическая. Какие-то ошибки могут исправлять месяцами (отмазки, типа человек который писал хранимку уже уволился, а она сложная).
Зато наш директор it, отчитался в свое время о завершении проекта и пошел вверх по служебной лестнице

Одна история про саботаж.
в 2007г внедряли УПП на одном региональном заводе. До этого весь учет между отделами и бухгалтерией велся только на "бумаге". Сотрудники завода, которые не заняты непосредственно на производстве - в основном женщины в старшем возрасте, приходили на работу ровно в 8, шли на обед в 12, уходили домой по звонку ровно в 5. Зарабатывали свою среднюю по городу копеечку и, конечно, сильно не хотели, чтобы в их размеренную жизнь кто-то вносил неразбериху, пусть даже и временно. Стояла какая-то своя бухгалтерская программа, Люди делали в ворде и экселе документы, относили в бухгалтерию, тетки в бухгалтерии брали в руки сдаваемые им бумажные документы и вводили в эту программу. Собственно, руководитель проекта сразу увидел проблему и заранее договорился в руководством завода, чтобы они разослали централизовано приказ, но не в стиле, что с этого момента мы начинаем работу в 1С, а в стиле, что с такого-то числа бухгалтерия принимает документы только распечатанные из программы 1С "со штрихкодом".И сразу после этого включили штриховое кодирование документов и раздали бухгалтерии сканеры. Каково было наше удивление, когда в потоке документов часть из них сканер не определял по штрихкоду. Долго ломали голову, как такое может быть, проверяли настройки сканеров, префиксы, постфиксы и тд. А проблема оказалось банальной. Некоторые сотрудники договорились саботировать внедрение 1С и продолжали делать документы в ворде и "рисовали" руками штрихкод прямо в ворде с поморью графических инструментов. Зона комфорта - она такая заманчивая )))

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

Мой первый проект в качестве руководителя проекта.

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

Задачи были от интеграции с производственной базой 1С 7.7 до переписки драйвера ККМ и РИБ на 50 узлов.

Итерации этапов работ закрывались слабо, далеко не с первой попытки.
По итогу работы с подрядчиком пришлось самостоятельно переписывать прямые запросы к SQL базе 1С7.7, своими же силами был переписан драйвер ККМ и правила обмена РИБ.

За почти год работы с подрядчиком успеха достичь не удалось. В итоге взял себе программиста одного в офис и еще одного фрилансера на пару месяцев.
Работа сильно ускорилась. Через три месяца мы внедрили систему.

Проект завершился успешно )))

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

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

- Нам стало интересно, как почему законченные блоки программы буксуют в бухгалтерии и написали / сформировали отчет по пользователям:


1) Главный бухгатер - "создано 3 документа" - "время в базе 1,5 часа"
2) Зам.главного бухгалтера - "создано 400 документов" - "время в базе 270 часов в базе"

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

1. внедряли в воинской части учет личного состава. И захотели перенести блок психологического тестирования из самописной конфигурации в нашу конфигурацию. Тексты тестов есть, вопросы есть, а алгоритм обработки - закрыт в коде. С начальником по воспитательной работе нашли выход: 10 вопросов по 4 варианта ответа на каждый вопрос = 1048576 вариантвов. Посадили 10 курсантов за компьютеры и за неделю перебрали все возможные варианты теста. Составили карту ответов, проанализировали и поняли алгоритм и перенесли в нашу программу. Все были довольны. В одной программе был и учет курсантов, и психологическое тестирование.
2. Поставлена задача автоматизировать проживание в вахтовых городках на газовых мегастройках нашей страны. Собрали совещание, пригласили 1С франчайзи. Стали обсуждать:
- Франчайзи поставили срок 6 месяцев на составление ТЗ и согласование доступов к личной информации ЗУПов организаций проживающих и вахтовых организаций.
- Программисты головной организации срок согласования только доступа оценили в 3 месяца. Требовали обязательное использование типовой КА (комплексной автоматизации) и справочников Сотрудники.
А надо как всегда "Вчера" - Дают 2 недели и даже премию обещали. Согласование долго...
И мы решили пойти своим путем: конфигурация с нуля, хранение на периодическом регистре сведений и регистре накопления, ключ сотрудника определялся парой полей "ФИО" - строка и ДатаРождения - Дата. Иногда можно было заполнять Паспорт и телефон, но не обязательно.
Первый день запуска был не очень удачный, т.к. использовался обычный принцип ввода информации в 1С: куча форм и табличек, заполнение полей выбором из справочников. В обычном интерфейсе нужно работать пользователям с опытом работы в 1С, а где таких на крайнем Севере найдешь?)))) Пришлось срочно переделывать (примерно как Google стала переделывать Android после презентации первого Айфона). Интерфейс минималистичный - один отчет на СКД - даже без программирования - по максимуму похожий на старую работу в XLS женщин комендантов городков. Там требуется заселить человека и выселить его.
При заселении: ищем в отчете свободную ячейку для заселения - тычим мышкой - запоняем ФИО и Дату рождения и ок. Обновляем отчет - человек живет.
Нужно выселить - ищем человека в отчете - тычим мышкой - все уже заполнено - нужно только кнопку нажать что он Выселен. Обновляем отчет - место освободилось.
В результате в ближайшие 3 месяца автоматизировали более 10 городков. А на некоторых городках обучение проводили по телефону в течении 5 минут с людьми, ни разу не видящими 1С и те начинали работать. После этого представители других организаций без долгого согласования сами захотели предоставить данные о своих сотрудниках, чтобы быстрее формировать заявки на проживание и отчеты. Поэтому успех внедрения зависит от умения анализировать предметную область.

Внедряли мы как-то проект в одной крупной российской компании и в процессе разработки функционала запросили у бизнес-эксперта нужную нам информацию (а именно файл Excel и правило его заполнения). Эксперт отправил нас к конечному пользователю, обычному сотруднику - молодой девушке. Мы ждали от нее нужной нам информации достаточно долго: то она говорила, что еще немного нужно подождать, она скоро даст, то просто отмалчивалась.
В тоге от других "доверенных" лиц со стороны Заказчика узнали, что она каждый день истерила по поводу того, что она не будет давать нам никакую информацию, что после этого проекта ее уволят и она не будет никому нужна. Ходила по всему офису и "плакалась". Она боялась, что мы полностью автоматизируем ее ручной труд и работодатель выкинет ее улицу.
В итоге ее руководителю пришлось оказать ей психологическую помощь и объяснить, что никто ее не собирается увольнять. После чего мы быстро получили нужный файл.
P.S. После внедрения девушка продолжила работать в компании и не пострадала))

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

Коллеги, добрый день.

Пост о пользе привлечения экспертов на проекты и о разработке кода в соответствии со стандартами фирмы «1С».

Делюсь правдивой историей из моей практики внедрения 1С:ERP. Проект, о котором пойдет речь, победил на конкурсе 1С:Проект года в 2017 году.

Итак, проект внедрения 1С:ERP по фреймворку SCRUM (Технология быстрого результата в терминах фирмы "1С"). Провели экспресс-диагностику, посмотрели серверное оборудование на предмет достаточности мощностей для 1С:ERP на 100 пользователей – фиксируем вывод что «железо потянет», но посмотрели только спецификацию оборудования специализированные тесты не проводили. На сам сервер Заказчик нас не пустил по соображениям информационной безопасности. Я понимал, что в сервере «лежит» риск. Для смягчения риска начал искать эксперта по технологическим вопросам.
Середина проекта, пользователи начинают активно работать и 1С:ERP начинает сильно тормозить, мало того, увеличено содержание проекта, теперь целевая 1С:ERP должна работать для 300 пользователей. Начинаем разбираться – «железо» на пределе возможностей, но должно тянуть. Привлекаю эксперта по технологическим вопросам, который за пару дней работы, запустив в том числе тесты Гилева, дает заключение: проблема не в «тяжеловесности» 1С:ERP, а в следующем:
1. Помимо 1С:ERP, на сервере стоит историческая система 1С:УПП сильно доработанная специалистами Заказчика и именно она «подвешивает» сервер СУБД (MS SQL) некорректными запросами, которые формируется доработанным «на коленках» кодом (не по стандартам разработки фирмы «1С»);
2. Железа будет НЕ достаточно для 300 одновременных сеансов;
Чтобы разрешить ситуацию считаю стоимость простоя предприятия из-за неработающей (висящей/тормозящей) 1С:ERP, получается 300 000 Р/час, тем самым обосновываю покупку нового сервера.
Мы не занимались поставкой оборудования и ИТ-отдел Заказчика подрядился собрать сервер по комплектующим самостоятельно. Для сравнения: фирменный сервер стоил около 2 млн. Р., бюджет сборки Сервера «на коленках» - 1,2 млн. Р.
В результате сервер собирался более 3-х месяцев, так как комплектующие заказывались по всему миру, наконец, сервер собран, но в процессе эксплуатации случились две проблемы:
1. Контроллеры не дружат с RAID-массивом (при работе с файлами размером более 4-х Гб скорость чтения/записи падает по экспоненте) – ошибка была исправлена спустя несколько месяцев, производитель контроллеров выпустил новые версии драйверов;
2. В один прекрасный день сгорели процессоры :-) – ИТ-директор, быстро купив процессоры, полетел в г. Стамбул исправлять поломку.
Для справки: стоимость простоя Предприятия из-за не работающей 1С:ERP = 300 000 Р./час, экономия на сборке сервера Noname максимум 800 000 Р.

Мораль сей были такова:
0. Работайте с рисками (диагностика, ранжирование, управление) – дешевле будет;
1. Не экономьте на технической экспертизе – много нервов и средств сбережете;
2. Не экономьте на контроле качества работ, выпуская продукт, соответствующий стандартам качества фирмы «1С» - представьте каковы последствия того, что Заказчик скажет: "...Ваша система не годна к использованию..." по завершении проекта;
3. Не экономьте на оборудовании – сейчас стоимость «железа» невысока.

Удачи на проектах!

Оводков Василий
Член Московского отделения PMI в России
Член International Project Management Association
Сертифицированный специалист по управлению проектами IPMA Level D
Сертифицированный 1С:Руководитель корпоративных проектов