Как заставить разработки работать

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

Методология - Проектирование - Техническое задание

Разработка Внедрение Обучение Функциональное тестирование Испытания Тестирование

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

Гладко было на бумаге, да забыли про овраги

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

Процесс проработки сценария испытаний можно представить в виде следующей диаграммы (для каждого бизнес-процесса прорабатывается свой сценарий):

 

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

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

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

 

К сценарию предъявляются следующие требования:

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

 

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

Однако испытания это ещё не все. Что бы система заработала, и затем работала без перебоев, необходимо обучить пользователей, а для обучения необходимо наличие методического материала, без которого обучение превратиться в импровизированное шоу. Я бы выделил 3 категории методического материала, который необходим для обучения и дальнейшей работы пользователей: инструкции, сценарии и регламенты.

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

  1. Перейдите Торговля – Номенклатура, откроется справочник Номенклатура:

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

  1. Укажите наименование номенклатуры:

  1. Нажмите Записать и закрыть;

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

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

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

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

 

Пришёл клиент с накладными

  1. Найдите накладную в 1С по номеру (номер на бумажной накладной у клиента);
  2. Соберите заказ на складе;
  3. Отразите расходный ордер в 1С;
  4. Вручите товар клиенту;

 

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

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

Не мешай системе работать

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

  • Программная ошибка;
  • Логическая ошибка функционала;

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

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

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

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

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

 

 

К1 – это конфигурация базы, которую эксплуатирует заказчик. Буква С в скобках означает что она стабильная. Стабильная – это значит, что пользователи в ней работают и не испытывают никаких проблем, т.е. система решает поставленные задачи. В какой-то момент в конфигурацию разработчик вносит изменение (не важно, либо редактирует прямо в рабочей базе, либо путём сравнения объединения), в результате получается конфигурация К2, но, так как после внесения изменений функционал в базе никто не тестировал (так как это бы привело к остановке работы в базе на какое-то время до завершения отладки), то конфигурация получилась нестабильной. Причём, она будет нестабильной, даже если тестирование делалось где-то в базе разработки либо тестовой базе, ведь сам момент внесения изменений в конфигурацию – это потенциальная возможность что-либо сломать, причём в самом неожиданном месте. Это как если вы сдадите автомобиль на СТО для ремонта двигателя, а забрав его, спустя время обнаружите, что у него повреждена краска на заднем бампере. Лишь только внесение изменений путём полной загрузки конфигурации, которая выгружена из полностью протестированной базы, даст гарантию стабильности функционала рабочей базы. Однако, такое возможно только если изменения в систему вносит один разработчик. В нашем случае, Изменение 2 вносит второй разработчик, путём сравнения объединения, в результате получается конфигурация К3, еще более не стабильная, причем в ней могут оказаться испорчены изменения 1-го разработчика.

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

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

Решением этой проблемы может стать функциональное и приемочное тестирование.

Функциональное тестирование

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

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

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

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

Все тесты стоит объединить в один реестр, и в дальнейшем, каждый раз прогонять их перед обновлением работающей системы. Ускорить процесс тестирования можно воспользовавшись специализированными инструментами, позволяющими его автоматизировать. Например, «1С:Сценарное тестирование 8», входящий в состав «1С:Корпоративный инструментальный пакет 8».

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

Для примера рассмотрим ситуацию:

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

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

Спустя некоторое время появилась необходимость обновить рабочую базу конфигурацией от того самого стороннего поставщика. Эта задача была поставлена другому разработчику, который в процессе обновления взял форму документа РТУ из конфигурации поставщика, потому как в ней было множество изменений от поставщика (о том, что на форму была добавлена новая команда он не знал и по неопытности не доглядел).

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

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

Заполнение РТУ себестоимостью

  1. Добавляет номенклатуру Перчатки;
  2. Отражает поступление перчаток (Поступление товаров) в количестве 10 шт по цене 100 р;
  3. Отражает Реализацию перчаток (Реализация товаров) в количестве 5 шт, цену заполняет себестоимостью;

Контроль: цена перчаток автоматически установилась 10 р;

 

Этот тест добавляется в реестр функциональных тестов.

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

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

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

Приемочное тестирование

Для примера рассмотрим следующую ситуацию (логическую ошибку):

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

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

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

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

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

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

 

Тест 1:

  1. Администратор (А): Добавляет пользователя Менеджер по продажам (МП);
  2. Менеджер по продажам (МП): Создает номенклатуру Шапка-ушанка;
  3. МП: Отражает поступление номенклатуры:

Номенклатура

Цена

Количество

1

Шапка-ушанка

100

5

  1. МП: Формирует отчет Анализ цен номенклатуры
    Контроль: Эталонный отчет «Анализ цен номенклатуры 1.mxl»

 

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

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

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

 

Обобщенный процесс разработки функционала

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

Допустим в какой-то момент имеется конфигурация Х2.0.6.15С. Первая буква Х означает что эта конфигурация находится не в рабочей базе, а в хранилище конфигураций, буква С означает что она стабильна. На основании этой конфигурации собран релиз (поставка) Р2.0.6.15, который распространён среди клиентов.

Далее принимается решение разработать новый функционал. Для этого разворачивается новое хранилище Х2.0.7.0 путём копирования хранилища Х2.0.6.15С. В новом хранилище начинается разработка и разработчики фиксируют из своих баз с конфигурациями КР3 и КР4 изменения с новым функционалом и в какой-то момент получается конфигурация с новым функционалом Х2.0.7.1Н (Н – нестабильная). Так как конфигурация 2.0.7 нестабильна, начинается процесс тестирования, посредством выполнения всех функциональных и приемочных тестов. Так как были выявлены проблемы в ходе тестирования, конфигурация по-прежнему нестабильна. Эти проблемы исправляются и получаем конфигурацию Х2.0.7.2Н. Так продолжается до тех пор, пока в процессе тестирования не будет выявлено ни одной проблемы и не получим стабильную конфигурацию Х2.0.7.5С, на основании которой можно собрать поставку и предоставить клиентам очередной релиз.

Если в процессе разработки функционала в хранилище 2.0.7 в релизе 2.0.6 клиентами обнаруживаются критические ошибки, не выявленные в процессе тестирования, их исправление выполняют разработчики в базах с конфигурациями КР1 и КР2, полученными из хранилища Х2.0.6.15С. После исправления изменения фиксируются в хранилище и полученную конфигурацию Х2.0.6.16Н тестируют. Параллельно эти же исправления вносятся и в хранилище 2.0.7, чтобы эти критические ошибки не попали в релиз 2.0.7, а внутренняя документация пополняется тестами, направленными на их отлов. Так как ошибок в конфигурации Х2.0.6.16Н не было найдено, она признается стабильной и выпускается релиз Р2.0.6.16, который предоставляется клиентам.

Важно понимать, что:

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

 

Если, в процессе разработки функционала для релиза 2.0.7 возникла потребность ещё в каких-то функциях, то принимается решение начать разработку релиза 2.0.8, хранилище которого разворачивается путём копирования хранилища конфигурации в состоянии Х2.0.7.1Н. В этом случае, по завершении разработки в хранилище 2.0.7 изменения, которые были в него внесены начиная с состояния Х2.0.7.1Н должны быть перенесены в хранилище 2.0.8.

Итоги

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

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

 

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

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

 

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

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

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. weissfeuer 39 02.04.16 23:16 Сейчас в теме
А те, кто поставил плюсы, читали вообще публикацию? Или за красивые схемки поставили? Это же трэш, начиная с первого абзаца: "Условно внедрение можно разбить на два этапа: подготовка и пуск" WTF?!!

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

Хочешь научиться писать человеческим языком, вот тебе хорошая ссылка http://maximilyahov.ru/hello/
IgorS; Award; mr.lynx; dabu-dabu; so-quest; Nelli_A86; pavlov_dv; EliasShy; dj_serega; ZOMI; Messenger Unchained; +11 Ответить
2. liurn 52 03.04.16 10:28 Сейчас в теме
(1) weissfeuer, ощущение, что комментарий писал закоренелый анархист и брюзга: обгадил все фигурально и ничего по существу. Если хочешь поласкать свой нежный литературный слух - почитай классиков. Здесь авторские публикации не для конкурса красноречия, языком кто как умеет, а не как нравится именно тебе.
jerry_maguire; +1 1 Ответить
9. weissfeuer 39 03.04.16 15:17 Сейчас в теме
(2) поржал)))). По существу - у меня все замечания конкретные, нет ничего фигурального. И даже "что делать" написано - не поленитесь прочитать статью по ссылке.
10. liurn 52 03.04.16 19:01 Сейчас в теме
(9) weissfeuer, если есть что возразить по предложенным способам решения обозначенных проблем - изложи, может вместе поржем, и это будет по существу. Иначе не вижу смысла продолжать наивный спор у кого фразы витиеватее а у кого замечания фигуральнее. Все равно каждый при своём останется.
Что касается того что мой стиль изложения пришёлся кому то не по душе - это я понял. Не нужно одно и то же писать по несколько раз. Но всем не угодишь и о стилях не спорят. И это не по существу.
5. liurn 52 03.04.16 13:36 Сейчас в теме
(3) liana-banana, так и до стольба можно докопаться, что плохо стоит
7. Messenger Unchained 03.04.16 13:49 Сейчас в теме
(5), (6) - оу, у нас появился еще один Лустин, который "вставляет пасхальные закладки/опечатки в публичных блогозаписях" чтобы что-то понять и доказать?
8. liurn 52 03.04.16 14:23 Сейчас в теме
(7) Messenger Unchained, понять свои ошибки я не прочь, но доказывать что-то кому-то - дело не благодарное
11. Messenger Unchained 03.04.16 20:51 Сейчас в теме
(8) ты прав. Заканчиваю доказывать.
4. Messenger Unchained 03.04.16 11:50 Сейчас в теме
2) в (1) написана совершенная правда.
Если бы публикация была техническая, то за идею и ее разворачивание можно многое и простить.
Но суть твоей публикации сводится к очередному обмусоливанию каких-то сакральных тайн.

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

Так и видится вскипевший пользователь, убеждающийся в том, что товары местонаходятся
6. liurn 52 03.04.16 13:43 Сейчас в теме
(4) Messenger Unchained, не буду спорить, что тот кто не в теме увидит здесь сокральную тайну.
А что не так с местонахождением?
12. so-quest 132 04.04.16 14:03 Сейчас в теме
Два раза прочитал, но так и не понял - что рекламируют? У Лехи хоть названия продуктов и ссылки на его разработки и сообщество. А тут кроме менеджерского словоблудия - ничего...
И "это" рекомендуют эксперты.
16. pro-rok 254 06.04.16 08:27 Сейчас в теме
(12) so-quest, тут не рекламируют, а делятся опытом и подходами.
По поводу стиля, хочу сказать, ЧТО ВЫ ПРИДИРАЕТЕСЬ. Человек решил опытом поделиться, а вам витиеватые фразы не понравилось, согласен что читать сложно, но это не главное.
Относительно статьи, идея хорошая , хотя и не новая. на мой взгляд, было бы очень полезно если бы данная статья содержала в себе краткий кейс.
13. liurn 52 04.04.16 22:44 Сейчас в теме
Под натиском критики отредактировал анонс
15. Messenger Unchained 04.04.16 23:49 Сейчас в теме
(13) отлично! Специалисты первой линии поддержки на крупном федеральном предприятии, где как раз внедряют 1С, уже оценили!
14. mulla1979 9 04.04.16 23:44 Сейчас в теме
А что, нормальная статья, только букв много...Я бы разделил статью на 2 части (до "не мешай системе работать" и остальное). А по смыслу все правильно написано! Я в данный момент работаю специалистом первой линии поддержки на крупном федеральном предприятии, где как раз внедряют 1С, и все эти проблемы прямо как на ладони! Причем в комплексе... Поэтому, в качестве ликбеза для начинающих внедренцев и разработчиков эта статья будет в точку! Автору плюс!
17. МимохожийОднако 130 06.04.16 08:47 Сейчас в теме
Статья хороша как реферат для преподавателя, но для практики малопригодна.
18. AlexWhite 191 06.04.16 09:02 Сейчас в теме
необходимо разработать тест для каждой функции и включить его в реестр тестов
- на чем разрабатывается функциональный тест, кто, в какой момент его должен разработать и что из себя представляет реестр тестов?
22. liurn 52 06.04.16 22:19 Сейчас в теме
(18) AlexWhite, описать формально текстом может и разработчик, если нет тестировщика. Разрабатывается когда реализована очередная функция, главное - до того как начнётся тестирование. Реестр тестов - например текстовый документ, где каждый раздел - это тест. Это уже конкретный инструмент, кому что нравиться, не буду навязывать своё мнение. Если использовать 1с:сценарное тестирование - сама база и будет реестром. Не стал вдаваться в такие подробности, так как в этом случае меня вообще местные критики линчевали бы )
19. AlexWhite 191 06.04.16 09:28 Сейчас в теме
По "обобщенной схеме разработки" появились вопросы - не понятно, Х2.0.6.16Н (нестабильная), после тестирования превращается в стабильную Ч2.0.6.16С, но потом, почему-то, попадает в рабочую Р2.0.6.15 или это ошибка на схеме?
Кто, каким способом, следит, сколько ветвлений произошло, какая ветвь, в какой момент годится для внедрения в рабочую конфигурацию, каким образом рабочие конфигурации связаны с конкретными ветвями разработки и тестирования?
23. liurn 52 06.04.16 22:23 Сейчас в теме
(19) AlexWhite, да, это опечатка. Должно быть Р2.0.6.16. Спасибо, исправлю как нибудь.
20. Yashazz 3328 06.04.16 17:13 Сейчас в теме
Очередные рассуждизмы ни о чём. Когда уже все высокоумные господа-в-галстуках, трущиеся вокруг IT, поймут, что единственное - именно единственное, - что является залогом успешного
внедрения - это административный ресурс. Скажут жрать кактус - будут колоться и жрать. Не скажут - вы их ничем не соблазните, хоть наизнанку вывернись.

А то всё схемы, графики, заумь-то какая, простихосспади.
21. liurn 52 06.04.16 22:12 Сейчас в теме
(20) Yashazz, вы меня с кем то путаете. Не будь я жертвой приказов жрать кактусы - никогда бы не занимался тем чем занимаюсь.
24. liurn 52 06.04.16 22:29 Сейчас в теме
Отредактировал статью, уменьшил количество букв. Надеюсь сейчас она будет меньше раздражать и проще читаться. Спасибо за комментарии, в том числе и отрицательные.
А для любителей рекламы - добавил, рекламу продуктов 1С.
25. Sairys 16.04.16 12:24 Сейчас в теме
Небольшая ошибка в тексте "Собственный и заимствованный опыт позволили выработать подходы к решению некоторых их них."
Оставьте свое сообщение

См. также

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

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

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

24.01.2019    9678    user809424    11    

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

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

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

26.06.2020    3866    1c-intelligence    15    

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

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

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

08.06.2020    4433    stepan96    12    

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

Техническое задание Бесплатно (free)

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

28.05.2020    7895    sapervodichka    70    

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

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

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

29.06.2017    34002    1СERP    79    

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

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

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

25.05.2020    5103    sapervodichka    1    

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

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

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

18.05.2020    10271    MariaTemchina    33    

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

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

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

23.03.2020    5273    MariaTemchina    24    

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

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

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

09.06.2017    30881    1СERP    175    

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

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

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

03.03.2020    5944    VLikhobabin    44    

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

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

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

23.01.2020    12078    MariaTemchina    8    

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

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

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

09.01.2020    6224    roman72    0    

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

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

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

18.04.2017    31720    1СERP    189    

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

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

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

14.10.2019    5890    chavalah    16    

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

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

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

19.09.2019    12061    ogroup    163    

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

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

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

16.09.2019    9443    GSoft    15    

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

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

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

10.04.2017    31612    1СERP    107    

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

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

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

30.08.2019    11436    SergeyN    6    

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

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

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

20.08.2019    8523    KoldunOne    7    

Impact mapping: чем он может быть вам полезен

Техническое задание Бесплатно (free)

Привет, коллеги! Сегодня хочу поговорить про один из инструментов Владельца продукта - Impact mapping (карта влияния). Чем он хорош и почему его стоит использовать.

26.07.2019    6444    slozhenikin_com    14    

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

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

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

03.04.2017    42280    1СERP    231    

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

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

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

28.06.2019    7846    SergeyN    1    

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

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

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

19.06.2019    10074    FB_10160810658600104    62    

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

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

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

18.06.2019    7432    MariaTemchina    8    

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

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

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

23.02.2017    27455    Gavrik    10    

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

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

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

31.05.2019    8798    MariaTemchina    23    

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

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

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

14.05.2019    11094    1c-intelligence    121    

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

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

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

06.05.2019    7418    MariaTemchina    8    

Как оценивать задачи программисту 1С Промо

Техническое задание Россия Бесплатно (free)

Оценивать задачу всегда сложно. У меня не всегда получается оценивать задачи адекватно (во всяком случае, не всегда моё ощущение адекватности совпадает с ощущениями других участников процесса). Именно по причине того, что вопрос для меня актуальный, хочу поделиться своими размышлениями, субъективным опытом в этом вопросе. Речь пойдет только о технической оценке.

11.08.2016    33492    SamBadi    52    

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

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

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

04.05.2019    8899    1c-intelligence    39    

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

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

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

15.04.2019    11417    MariaTemchina    15    

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

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

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

13.02.2019    8164    chavalah    22    

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

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

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

17.06.2016    40031    raiml    37    

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

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

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

12.02.2019    9832    MariaTemchina    20    

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

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

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

04.02.2019    10021    1c-intelligence    64    

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

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

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

31.01.2019    8222    MariaTemchina    0    

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

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

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

26.12.2014    44478    CheBurator    64    

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

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

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

14.01.2019    10038    MariaTemchina    13    

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

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

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

10.01.2019    12746    chavalah    123    

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

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

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

26.12.2018    9738    1c-intelligence    7    

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

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

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

1 стартмани

14.09.2015    36174    axxell    15    

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

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

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

19.12.2018    9685    MariaTemchina    24    

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

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

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

09.12.2018    9088    chavalah    119    

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

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

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

05.12.2018    16924    andironenko    128    

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

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

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

06.04.2015    37613    raiml    14    

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

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

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

03.12.2018    8618    capitan    26    

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

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

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

26.11.2018    10007    MariaTemchina    40    

Памятка руководителя: Будьте оптимистичным или на крайний случай злым

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

Следующая статья из цикла Управление персоналом - в этот раз предлагаю обсудить вопросы психологии управления и подчинения. Для тех, кто начинает читать этот цикл с этой статьи, вот ссылка на прошлый материал https://infostart.ru/public/937923/, в конце статьи будут ссылки на все статьи из серии «Памятка руководителя» - читатели просили. Итак, продолжаем работать с персоналом.

22.11.2018    12402    andironenko    43    

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

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

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

16.11.2014    28669    raiml    46    

Создание концепции проекта (project scope statement). Курс по управлению проектами, часть 8

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

Что такое концепция проекта? Это понятие, близкое по смыслу к техническому заданию (ТЗ). Одно из определений концепции - детальное, целостное описание работ в удобной для команды форме.

19.11.2018    7982    Selikhovkin    2    

Роевой интеллект (Swarm intelligence) как метод управления проектами (анти-утопия)

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

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

19.11.2018    9326    capitan    41    

Почему внедрение ERP-системы не приносит пользы бизнесу?

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

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

15.11.2018    22830    rossoxa    66