Поддержка пользователей как фактор успешности проекта

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

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

Я являюсь руководителем отдела поддержки пользователей в одном очень крупном российском производственном холдинге. Суммарно в наших системах на базе 1С сейчас работает свыше пяти с половиной тысяч пользователей. Мой отдел занимается поддержкой – где-то 500 активных аккаунтов на поддержке. Я попробую поделиться с вами своим опытом: что и как бывает, что как работает. Статья написана по итогам доклада, прочитанного автором на Конференции IE 2013 Еvolution 23-24 мая 2013 года. Также она напечатана в Журнале Инфостарта №2.

 

Качество проекта внедрения программного продукта

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

Для меня самое понятное определение термина качество – это соответствие ожиданиям. Соответствие ожиданиям того, кто заказывал проект.

Вроде бы, все понятно. Правда, ожидание – такой «плавающий» фактор. Но, я думаю, если не у всех, то у многих были в практике такие проекты, когда пришли и за полгода внедрили автоматизированную систему на базе типового продукта. Чудесным образом бюджет был соблюден, сроки отклонились совсем ненамного, с ресурсами тоже вроде как угадали. Пришли к заказчику: «Вот, все получилось». Заказчик говорит: «О, все здорово!» Не верите? Ну, вообще-то, успешные проекты все-таки встречаются.

А как часто происходит потом? Проект запускается в эксплуатацию, в этот момент мы подписываем контракт на ИТС и уходим. Проходит год. Мы возвращаемся к клиенту, потому что у нас заканчивается подписка ИТС, и говорим: «Ну все, у тебя льготный период закончился. Давай подписывать ИТС». И тут, внезапно, нам заказчик говорит: «Да, вообще-то, вроде бы система-то не очень. Внедренные отчеты не работают. Я был вынужден нанять двух местных программистов, которые мне дописывали что-то. У них тоже ничего не получилось. И, на самом деле, я сейчас уже готовлю бюджет на внедрение SAP. В общем-то, ИТС никакого не будет.»

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

 

Долгосрочная составляющая качества

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

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

  • Во-первых, результаты проекта востребованы и после окончания проекта – иначе, зачем мы его делали. Хотя бывают и разовые проекты, и не только в IT-отрасли.
  • Во-вторых, результаты проекта приносят ценности в течение длительного времени – иначе, опять же, мы внедряем ERP-систему, мы внедряем учетную систему. Чем больше у нас данных в учетной системе, тем больше мы ее используем, тем больше результата она нам может дать. Соответственно, и наши результаты проекта должны быть долгосрочно востребованы.
  • В-третьих, очень важный тезис - изменения не разрушают систему. То есть, абстрактный пример, который я привел, когда пришел местный программист из соседней деревни, добавил новый документ «Планирование ремонта». 37 регистров на него написал. И внезапно у нас расползся БДР. Вот если мы так проводим изменения, тогда у нас система разрушается. Долгосрочного качества мы не достигаем.
  • В-четвертых, опять же, мегаважный тезис - заказчик понимает и (важно!) принимает стоимость владения.

Вопрос – как же это все измерить? Как же понять, что у нас с проектом все хорошо в долгосрочной перспективе? Как же моментально узнать – с ним все хорошо или нет?

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

Идешь к пользователю и спрашиваешь его: «оцени свою удовлетворенность по трехбалльной шкале – не доволен/так себе/доволен». Если все довольны, значит, все хорошо. Даже если система за год стала совершенно другой, но все довольны – это хорошо! Это значит - система живет, система развивается.

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

 

Что же заботит пользователя?

 

  • Итак, первое. У нас может быть мегакрутая система. Но если я, как пользователь, в нее не могу зайти… Вот прямо сейчас мне потребовалось зайти в систему, и у меня это не получилосьмне такая система не нужна. Там может быть 37 панелей-индикаторов, красивые картинки, супер-интерфейс. Но если мне в нее не зайти, или я могу в нее зайти, но она мне не отвечает – такая система мне не нужна.
  • Второе – очень важный эмоциональный фактор – работа не является для меня обузой. Зачастую мы,когда внедряем ERP-систему, ориентируемся на задачи финансового директора. Но информацию в эту ERP-систему, так или иначе, добавляют пользователи. И если пользователь считает, что его заставили это делать – он будет сильно недоволен. Например, мы приходим к мастеру участка и говорим – «ну все, у тебя внедрили информационную систему – теперь ты заносишь данные». И это нормальное сопротивление человека, когда он говорит «Я мастер участка, мне не нужна система, у меня все ок». Система становится для него обузой. Так вот: когда система для пользователя обузаон ей не рад, он не любит ее.
  • Третье – тоже очень важное состояние пользователя: «Я знаю, что я знаю, как отразить операцию». Вот я с этого начал, что прошло очередное обновление и, внезапно, у документа «Перемещение товаров», которым я пользуюсь несколько раз на дню, изменилась форма. Мне нужно подумать, найти эти поля, включить голову, эмоционально напрячься… Но, когда такое происходит, я теряю уверенность, что завтра, зайдя в программу, я смогу отразить эту операцию. То есть, я перестаю быть уверенным в программе.
  • Четвертое – это «прописной» тезис: «Я знаю, куда обратиться, если у меня что-то не получается, и уверен, что там мне помогут».
  • Пятое – «Я верю отчетам системы и использую их в своей работе». Иначедля чего нужна система? Если я ей не верю или я ею не пользуюсь – тогда она для меня обуза.
  • И, наконец, очень важная «фишка» - «В программе есть что-то лично для меня». Я общался с пользователями – и, в основном, конфликты с пользователями решаются таким образом – «Давайте мы что-нибудь для вас сделаем». Это не нужно воспринимать буквально, я не призываю делать из программы зоопарк. Можно просто рассказать, что мы это сделали для вас. На самом деле, это нужно было всем пяти с половиной тысячам, но мы каждому сказали, что это было сделано специально для него.

 

Доступность системы

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

Здесь, я считаю, бескомпромиссный слайд:

  • Администратор у системы должен быть. Об этом написано везде. Приходите к заказчику и говорите там: «Системе нужен администратор, неважно, штатный это администратор или приходящий, но администратор должен быть. Причем он должен быть постоянный, и он должен быть обучен, он должен понимать, что он делает». Например, мы покупаем машину, мы на ней ездим. Если мы в нее не заливаем масло, мы едем первые 20000 километров хорошо, потом хуже, потом еще хуже… А потом нам выставляют счет на ремонт. Без администратора в нагруженной системе все то же самое. Когда клиент пытается сэкономить на администраторе, здесь нужно просто прямо бескомпромиссно доказывать клиенту, что такого нельзя делать. Почему я считаю, что можно клиенту разъяснять необходимость привлечения администратора? Потому что раньше у меня была работа во франчайзинге, а сейчас у меня опыт работы со стороны клиента. И я, как клиент, вменяемый. Если мне нормально объясняют, зачем это надо делать (если мне приводят аналогию с машинным маслом), я начинаю понимать.
  • Если у вас больше 100 пользователей, приложите усилия во время проекта, чтобы пользователи заводились идентично. В таком случае вы решите массу проблем по поиску того, а почему же у одного пользователя все хорошо, а у другого – плохо.
    • Вот смотрите, давайте на примере УПП возьмем. Там есть чудный механизм Профили доступа. Поставьте правило, что все пользователи работают на профилях. И этот список профилей более-менее ограничен.
    • Или вы ставите другое правило, что вы каждому назначаете индивидуально роли. И каждого пользователя индивидуально настраиваете.

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

  • Еще одна такая прописная истина – обязательно должен быть документ DRP (Disaster Recovery Plan), план восстановления – по-всякому можно называть. Это документ, где прописано, где лежит дистрибутив, где лежат архивы, какие особенности установки. Да, этот документ нужен только тогда, когда случилась авария. Но вот, не дай бог, она у кого-нибудь случится. Даже если вы, во время того, когда у вас упал сервер,будете лезть на интернет-сайт для того, чтобы скачать дистрибутив, а потом вспоминать, какую версию драйвера нужно установить – у вас прибавится два часа работы. А если ваша система высоконагружена, и пользователи требуют, чтобы она работала – значит, вы на два часа отклонились от своих договоренностей.

 

Пищевая цепь потока информации

Дальше – более веселый слайд.

Вот мы работаем с информационными системами. У меня родилась такая картинка – «Пищевая цепь потока информации». Только я ее сейчас попробую рассмотреть с самого окончания этого потока.

Вообще, у нас есть заказчик, да? Это финансовый директор, директор, начальник цеха, бухгалтер –кто угодно. По аналогии с «Кто банкует девушку, тот ее и танцует», заказчик – это тот человек, который «танцует» проект. Обычно ему нужен достаточно простой, ощутимый, измеримый итоговый результат. Назовем этот результат образно – «отчет».

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

Внимание! В информационную систему информация попадает с рук пользователей. Есть системы, которые сами снимают датчики (АСУТП) – например, проходы, чековая статистика и пр. Но, по большей части, в заполнении информационной базы участвуют пользователи.

Ну а пользователи получают информацию из внешнего мира либо из внутренних процессов.

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

Так вот смотрите. Мы с вами – внедренцы. Внедряем, поддерживаем, разрабатываем и т.д. Давайте задумаемся, на что мы можем влиять? На заказчика? Да вряд ли. На внешние события? Ну… как-то можем. Но не сильно.

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

 

Работа в программе не должна быть обузой

Информационная система для пользователя должна быть другом и товарищем.

Здесь изображена форма документа «Поступление товаров и услуг» из демо-версии последнего релиза УПП.

Как вы думаете – сколько на этой форме элементов управления?

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

Я ни в коем случае не хочу сказать, что это плохо. Это функционал, который позволяет нам отразить множество операций. Но: это то, с чем общается пользователь. Фигурировал тезис, что «Право выбора давать нельзя». Вот здесь, как раз, пограничное такое состояние – что «давать или не давать».

Это касаемо интерфейса. Это то, с чем работает наш пользователь.

Кроме того, что у нас такой перегруженный интерфейс, есть еще пара немаловажных моментов:

  • «Молчаливость» работы. Сейчас в управляемом интерфейсе при длительных операциях хотя бы крутится индикатор – идет заполнение книги покупок. Чаще всего, пользователь просто видит эти «часики», про которые – он уже знает, что нажми <Ctrl + Alt + Esc> (сними задачу) и запусти заново, и, может быть, все получится.
  • Ну и неинформативность сообщений тоже. У вас где-то там не хватает остатка… Где не хватает? Почему не хватает? Зачем?

То есть, вы понимаете, у нас есть такая система. Казалось бы, все плохо. Но мы же работаем. Мы же делаем удачные проекты.

 

Как пользователь узнает систему?

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

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

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

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

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

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

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

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

Но все равно – 80% информации в системе дают пользователи, которые в своей жизни используют 5-7 видов операций.

Как нам упростить им жизнь? Ответ банальный. Для них нужно написать инструкцию.

Но какие инструкции мы пишем? Чаще всего мы пишем инструкции по доработкам – то, что мы доделали. Либо инструкции, очень похожие на описание.

 

Какими бывают инструкции

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

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

Я приведу пример. У нас на предприятии внедряется новая HR-система (не 1С), и она перешла ко мне в отдел на поддержку. Плюс (у нас изменился немножко процесс) я должен забивать теперь два раза в месяц табель учета рабочего времени. Я честно, как самый обычный пользователь, прогулял все обучения. Я же айтишник, я же ого-го сколько этим занимаюсь!!! Что ж, я не разберусь, как табель завести?

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

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

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

В итоге я заставил написать функциональную инструкцию. Она заняла два листа. Эта инструкция отвечает на простой вопрос: как завести табель в систему – без каких-либо отклонений. Просто десять шагов: открыть/ввести/закрыть. Я ее беру, по пунктам делаю – и все получается!

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

 

 

Требования к функциональной инструкции

Я выписал, как я понимаю требования к функциональной инструкции:

  • Функциональная инструкция должна быть понятна и доступна пользователям минимального уровня подготовки (базовые навыки компьютера и возможность осуществлять процесс в действительности)
  • Функциональная инструкция должна начинаться с вопроса: «Как мне это сделать» либо «Что мне делать в такой-то ситуации?» Например: «Как оформить поступление машины абрикосов в кондитерский цех?», «Как оформить заказ покупателя на спальные матрасы?»
  • Чаще всего сперва уточняется, какая информация уже должна быть изначально. То есть, я же табель забиваю на основании того, что я знаю – кто у меня как работал. Если я, например, только что вернулся с отпуска и мне еще ничего не рассказали, документов/журналов никаких не предоставили – я табель не забью. Мне нужно сначала посмотреть, кто как являлся (получить сначала эту информацию).
  • По шагам необходимые действия в системе с минимальной вариативностью и описание, как еще можно сделать то же самое. Главное - в функциональной инструкции вариации не нужны. Да, она покроет не все 100% случаев. В лучшем случае – она покроет 10% случаев. Но это будут именно те случаи, которые чаще всего используются в рамках вашего бизнеса.
  • Обязательно указание, как проверить, что все корректно. Важно, что пользователь должен сам себя проверить. Иначе, проверять за него будете вы.
  • Разбор возможных ошибок лучше в конце, по тексту только наиболее вероятные ошибки, с указанием, что делать. Все отклонения и работу над ошибками лучше сместить на конец инструкции. То есть, когда мы берем инструкцию от СВЧ-печи – у нас там в конце табличка: «У вас не зажегся индикатор? – сделайте вот это», «У вас не открылась крышка? – отвезите ее в сервис».

 

Функциональная инструкция – гарантия корректной работы пользователей

Вот смотрите, сейчас кто-то скажет: «Сейчас нам еще один вид документа писать… Это долго». На самом деле, это три листа максимум. Даже двух листов будет достаточно. Обычно написание подобной инструкции занимает не более 2-х часов. 20 функциональных инструкций (кейсов) на достаточно крупное предприятие, я вас уверяю, – это хороший, более чем достаточный объем. В итоге – это 40 часов. Это не такой большой бюджет для гарантии того, что пользователи будут делать все единообразно, и будут вводить информацию единообразно. 

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

 

 

ServiceDesk – служба поддержки пользователей

Наша служба и опасна и трудна, и на первый взгляд как будто не видна. 

  • ServiceDesk предназначен для решения вопросов пользователей, связанных с работой в ИТ системах. Давно слышал такую поговорку: самый лучший айтишник – это тот, которого никто не знает. На самом деле, так оно и есть, потому что призвание службы ServiceDesk (службы помощи клиента) – это помочь пользователю. Это, как у скорой помощи, либо как у пожарных. Например, мы курим в кровати, и из-за нас случился пожар. И да, мы знаем, что это мы виноваты, но мы звоним в пожарную службу, чтобы нам помогли.
    И пользователь точно с таким же настроением обращается в поддержку.
    Поэтому, когда поддержка начинает говорить: «У-у-у… Что ж вы тут наделали!» Пользователь начинает думать: «Слушай, ну я и так знал, что я тут что-то наделал! Я тебе что позвонил-то, что обратился?»
    Вот здесь очень важно понимать, что любой ServiceDesk предназначен для того, чтобы помочь. Потом скорректируем. Потом расскажем, где он был не прав. Потом там все сделаем. Но вначале – помочь.
  • Это книжный тезис: основной показатель качества работы службы – отношение количества запросов пользователей, выполненных в срок, к общему поступившему количеству запросов.
  • На предприятиях с числом активных пользователей более 100 имеет смысл делать организованную службу поддержки (штатные специалисты либо отдельный контракт с аутсорсером). То есть, я рекомендую большим предприятиям иметь свой ServiceDesk – не обязательно штатный, можно заключить договор с франчайзи. Но тут есть особенность. Я, насколько понимаю, здесь большая часть франчайзеров. Вы, когда с клиентом договариваетесь о поддержке, вы не просто в договоре пишите, что будете оказывать поддержку, – вы хоть что-то пообещайте. Пообещайте, что вы зарегистрируете его запрос и хоть какой-то ответ дадите хоть в какой-то срок. Когда мне приходит шаблонный договор на ИТС, я его читаю и плачу.  Я понимаю, что я заключаю договор банальной доставки дисков к себе на предприятие. Хотя, казалось бы, ИТС – это информационно-технологическое сопровождение.
    На самом деле я кланяюсь фирме 1С, потому что сейчас содержание диска ИТС – это просто конфетка. Но я ведь договор заключаю не с фирмой 1С, которая так хорошо потрудилась и сделала такой диск, а с франчайзером, который мне его привозит. Поэтому, когда вы заключаете договор поддержки, не надо так поступать с клиентами – им это не нравится.

 

Организация работы службы сервис-деска

На что обратить внимание при создании сервис-деска

  • Обязательно, при любом построении процессов поддержки, зафиксируйте и стойте с кровью в руках (в зубах) над точкой входа: телефон или e-mail. И с самого начала требуйте обращаться именно по этому интерфейсу.
    Когда вы сделаете службу поддержки – один человек, два, телефон – все, что угодно. Когда вы сделаете такую службу, в которой один человек звонит, другой пишет письмо, третий – обращается через директора, а четвертый подходит сам – вы не сможете этим управлять. Вы не сможете зафиксировать время начала отсчета. При оказании поддержки это очень важно. Договоритесь с заказчиком, как вы принимаете запрос. Потому что именно по этому параметру вы будете фиксировать время начала отсчета.
  • Далее необходимо определить метод хранения запросов пользователей (Дата обращения, Инициатор, Содержание вопроса, Дата передачи ответа, Исполнитель, Краткое содержание ответа).
    Когда я два года назад пришел в компанию – сервис-деск работал на Outlook. Отлично работал. Ничего не надо было. На сервис-деске было пять специалистов, и количество запросов в день не превышало 20-50. Обычный Outlook с системой флажков работал идеально. Плюс один запрос, который это все вытягивал в базу данных.
    На самом деле Excel тоже будет работать хорошо. Соизмеряйте инструмент с объемом обрабатываемой им информации. Не нужно сразу вдаваться в поиск инструмента.
    Когда будет большой объем, посмотрите на хорошие системы с префиксом ITIL, еще что-то…  Да, там есть много вкусного, много хорошего, но не нужно начинать с них сразу. Там может случиться такая же ситуация, что открываешь форму документа – и теряешься.
  • Договоритесь с Заказчиком о SLA (нормальный срок от 1 дня, если это не вопрос доступности).
    Никогда не поддавайтесь, и заказчики – никогда не требуйте от исполнителя моментальный срок реакции. Принцип SLA, описанный в ITIL, звучит так: мы гарантируем, что 95% ваших запросов будут решены в срок. Допустим, срок один день. То есть,я гарантирую, что в течение одного дня решу 95% запросов. Но, когда мы начинаем требовать, что все запросы должны решаться за один час – это может привести к тупиковой ситуации. Например, у нас на поддержке 100 пользователей и у нас есть 10 консультантов – и тут, по не зависящим от техподдержки причинам, все эти 100 пользователей нам послали запрос. 10 консультантов не хватит. Поэтому со стороны исполнителя абсолютно нормально выдвигать несоизмеримые бюджеты под требование срока решения 1 час. Просто об этом нужно разговаривать. Это понимают. Кто не сталкивался – понимает не сразу. Но, тем не менее, это аргументировано.
  • Служба поддержки существует для того, чтобы помогать пользователям решать их вопросы.

 

Процесс изменения и эксплуатации должен быть разделен

Самый последний тезис: «Разделяй и властвуй».

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

  • Из этого следует простой тезис: С точки зрения владельца бизнеса, изменения – это капитал, а поддержка – это текущая деятельность.
    Это к разговору о том клиенте, с которого я начал, который систему у себя внедрил, год с ней мучился и теперь уже не хочет на ней работать. Мы к нему придем через год и спросим – «А сколько у тебя стоимость владения?» Он скажет – «N-цать сотен тысяч». А начнем разбирать – он из этих десятков или сотен тысяч большую часть потратил на то, что ему там какие-то доморощенные программисты что-то меняли.  Хотя, он-то хотел поддержку, а ему что-то меняли.
    Вот здесь происходит разрыв сознания, и пока мы этот конфликт заказчику не объясним – мы никогда не сможем выстроить ни эксплуатацию, ни изменения. Это постоянно будет «тяни-толкай».
    Я рекомендую разделять поддержку и изменения на уровне бюджетов, на уровне контрактов. Франчайзерам – тоже советую.
  • При эксплуатации 1С изменения не прекращаются практически никогда: новый отчет, новая печатная форма, добавить реквизит, не нравится, как рассчитывается скидка и т.д.

 

Ключевые факторы изменений

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

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

 

 

Что учитывать при разработке

При развитии готовой системы следует:

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

 

 

Заключение

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

Я не рассмотрел только два:

  • «Я верю отчетам системы»
  • «В программе есть что-то лично для меня».

К сказанному еще хочу добавить:

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

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

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

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо свернутое
1. Inkeeper 10.07.15 12:13 Сейчас в теме
Спасибо большое за статью! Сохранил в закладки
2. Designer1C 341 10.07.15 12:46 Сейчас в теме
Обстоятельно. Полезный опыт. Благодарю !

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

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

Кроме того, описание на доработку, разработку дает и разработчику и Заказчику ощущение "Готового продукта". Который можно пощупать, даже не начав им пользоваться.
help1Ckr; +1 Ответить
3. sournk 27 15.07.15 10:42 Сейчас в теме
- Как организовано хранение функциональных инструкций?
- Как инструкции доведите до сотрудников? Как тот же новый кладовщик узнает где взять инструкцию по оформлению прихода фуры абрикосов?
- Как сотрудники узнают об и их изменении?
4. UR1 96 15.07.15 21:30 Сейчас в теме
Спасибо! Прекрасная статья полезная обеим сторонам.
5. danila_inf 16.07.15 16:14 Сейчас в теме
Очень хорошая статья.
Мое мнение - не хватает завершенности.
В виде инструкций, и конкретного примера.
Хочется увидеть инструкцию. Хочется конкретный пример по организации ServiceDesk. Как делятся обязанности между людьми, скрипты сообщений и прочее.
Автор поделись конкретикой пожалуйста.
6. xoxland 99 20.07.15 23:44 Сейчас в теме
Коллеги, доклад написан на основе нескольких проектов, из каждого я выносил что-то новое. Целью статьи ставил донести до сообщества важность задумывать об озвученных тезисах.
Из конкретики:
1. Идеального варианта хранения инструкций не нашел. Больше всего понравилось следующая комбинация:
- инструкции выкладываются на портал, сгруппированные по подсистемам
- к функциональным инструкциям прописываются теги и отдельно слова для быстрого поиска
- все функц инструкции также выведены в отдельную иерархию в разделе вопросы-ответы
- специалисты поддержки (авторы инструкций) при получении обращения, на который есть функц инструкция, вначале спрашивают знаком ли с ней пользователь, высылают если нет, только после этого приступают к детальному разбору

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

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

См. также

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

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

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

24.01.2019    9816    user809424    11    

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

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

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

11.09.2020    2058    alexandr.blinov    17    

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

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

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

04.09.2020    2490    MariaTemchina    22    

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

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

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

20.08.2020    2332    MariaTemchina    4    

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

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

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

29.06.2017    34285    1СERP    79    

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

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

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

26.06.2020    4152    1c-intelligence    15    

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

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

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

08.06.2020    4709    stepan96    12    

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

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

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

25.05.2020    5291    sapervodichka    1    

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

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

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

09.06.2017    31015    1СERP    175    

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

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

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

18.05.2020    10613    MariaTemchina    33    

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

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

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

23.03.2020    5527    MariaTemchina    24    

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

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

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

03.03.2020    6116    VLikhobabin    44    

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

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

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

18.04.2017    31896    1СERP    189    

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

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

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

23.01.2020    13845    MariaTemchina    8    

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

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

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

09.01.2020    6551    roman72    0    

Про одну Тётю

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

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

24.12.2019    6654    1c-intelligence    32    

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

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

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

10.04.2017    31908    1СERP    107    

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

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

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

14.10.2019    5949    chavalah    16    

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

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

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

19.09.2019    12210    ogroup    163    

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

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

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

16.09.2019    9620    GSoft    15    

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

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

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

03.04.2017    42641    1СERP    231    

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

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

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

30.08.2019    11878    SergeyN    7    

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

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

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

20.08.2019    8773    Arsen1986    7    

Быстрый старт: минимальный набор автоматизации типовых процессов

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

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

16.08.2019    8283    Hissin    18    

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

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

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

23.02.2017    27568    Gavrik    10    

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

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

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

28.06.2019    8000    SergeyN    1    

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

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

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

24.06.2019    6747    sbase    9    

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

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

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

19.06.2019    10201    FB_10160810658600104    62    

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

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

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

17.06.2016    40130    raiml    37    

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

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

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

18.06.2019    7550    MariaTemchina    8    

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

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

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

31.05.2019    9037    MariaTemchina    23    

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

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

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

14.05.2019    11166    1c-intelligence    121    

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

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

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

26.12.2014    44634    CheBurator    64    

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

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

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

06.05.2019    7562    MariaTemchina    8    

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

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

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

04.05.2019    8965    1c-intelligence    39    

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

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

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

15.04.2019    11674    MariaTemchina    15    

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

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

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

1 стартмани

14.09.2015    36265    axxell    15    

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

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

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

13.02.2019    8229    chavalah    22    

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

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

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

12.02.2019    9996    MariaTemchina    20    

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

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

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

04.02.2019    10081    1c-intelligence    64    

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

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

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

06.04.2015    37737    raiml    14    

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

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

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

31.01.2019    8328    MariaTemchina    0    

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

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

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

14.01.2019    10137    MariaTemchina    13    

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

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

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

10.01.2019    12839    chavalah    123    

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

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

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

16.11.2014    28765    raiml    46    

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

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

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

26.12.2018    9842    1c-intelligence    7    

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

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

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

19.12.2018    9818    MariaTemchina    24    

20 мыслей об ИТ-проектах, или 20 лет спустя.

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

В этой серии из 20-ти статей я готов поделиться своей практикой управления проектами. Примеры, опыт и только то, что проверено лично. Выбираем темы голосованием!

09.12.2018    9179    chavalah    119    

Бизнес-консультант в малом и среднем-бизнесе. Кто это и зачем он нужен? Промо

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

Я не буду здесь давать сухие определения, думаю, они никому не интересны. Бизнес-консультант – это тот самый человек, которого приглашают со стороны, чтобы он помог найти решение каких-то проблем. Также очевидно, что взгляд «со стороны» очень часто помогает выявить то, что вы никогда не обнаружите, будучи сотрудником компании. Я хочу с вами поговорить исключительно о бизнес-консультантах, которые работают с малым и средним бизнесом, т.к. с предприятиями с численностью сотрудников ориентировочно от 5 до 70 человек. Эта работа во многом отличается от того, что делают специалисты, которых привлекают в подобных случаях крупные компании. И, как раз, с этими нюансами есть смысл разобраться.

13.11.2014    27971    raiml    236    

Памятка руководителя: не играйте с деньгами

Управление проектом Личная эффективность Управление персоналом (HRM) Бесплатно (free)

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

05.12.2018    17059    andironenko    128    

Шаг назад и ... шаг назад (классификация внутренних проектов)

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

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

03.12.2018    8714    capitan    26    

Белая и пушистая рецензия на Чёрную книгу Скрам

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

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

26.11.2018    10151    MariaTemchina    40