Кто занимается настройкой программного обеспечения

Обновлено: 16.05.2024

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

Регламент разработки и внедрения программных продуктов

1. Общие положения

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

– определение сферы применения;

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

– определение требований к процедурам деятельности;

– разграничение прав и обязанностей участников деятельности;

– закрепление ответственности участников деятельности.

1.3.1. АИС – Информационная система, созданная для решения задач автоматизации деятельности и бизнес-процессов Предприятия, в рамках которой осуществляется внедрение Программного продукта.

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

1.3.3. Проект – задача на разработку и внедрение Программного продукта, регулируемая Техническим заданием.

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

– служебные записки – основания разработки (изменения) Проекта;

– план внедрения Проекта;

– протоколы тестирования Программного продукта;

– акт внедрения Программного продукта;

– иные документы, регулирующие процесс внедрения конкретного проекта.

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

1.4. Деятельность Предприятия по разработке и внедрению программных продуктов регулируется:

– утвержденными Техническими заданиями;

– другими нормативными документами Предприятия.

1.5. Участниками деятельности по разработке и внедрению программных продуктов являются:

– лица, заинтересованные в создании (изменении) функционала АИС;

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

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

1.5.2. Руководитель проекта назначается руководителем деятельности по разработке и внедрению программных продуктов и координирует в рамках настоящего регламента деятельность участников внедрения соответствующего Программного продукта.

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

– при необходимости обеспечивает руководителя проекта и исполнителей работ копиями АИС для разработки Программного продукта;

– интегрирует готовый Программный продукт в АИС.

1.6. Разработка и внедрение программных продуктов включает следующие процедуры:

1) постановка задачи и запуск Проекта;

2) написание и утверждение Технического задания;

3) выполнение работ по проектированию Программного продукта;

4) окончательное тестирование и приемка Программного продукта;

5) внедрение Программного продукта в АИС.

2. Постановка задачи и запуск проекта

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

– АИС, которую необходимо создать (модифицировать);

– деятельность (процессы), подлежащие автоматизации;

– требования к функционалу АИС;

– срочность реализации с указанием обоснования реализации Проекта в срочном порядке;

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

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

2.2. Сферой действия настоящего регламента является автоматизация следующих задач:

– проекты на разработку и внедрение новых АИС;

– проекты на разработку и внедрение Программных продуктов, существенно изменяющих (дополняющих) функционал действующих АИС.

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

2.3. Основаниями для признания существенными изменений (дополнений) функционала действующих АИС являются следующие условия:

– важность Проекта (о потребностях в реализации Проекта в письменной форме заявило несколько лиц, заинтересованные в создании (изменении) функционала АИС, из различных подразделений Предприятия);

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

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

2.5. Если Проект не попадает в сферу применения настоящего регламента, то принятие решений о реализации Проекта настоящим регламентом не регулируется.

2.6. План внедрения проекта должен содержать, как минимум, следующую информацию:

– ответственных за выполнение работ;

– при необходимости исполнителей работ;

– оценки объема работ в часах;

– нормативные сроки завершения работ.

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

2.7. Руководитель проекта выполняет следующие функции:

– анализ возможностей и способов внедрения Проекта;

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

– координация действий участников внедрения Проекта;

– проведение консультаций с участниками внедрения для решения спорных вопросов;

– назначение исполнителей работ по Проекту;

– тестирование Программного продукта.

3. Техническое задание

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

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

3.3. Техническое задание должно содержать в себе, как минимум, следующую информацию:

– наименование и краткую характеристику АИС;

– назначение и функции предмета разработки;

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

– требования к АИС, в т.ч. технические требования (аппаратные и системные требования и т.п.), условия работы (требования к квалификации пользователей, порядок обслуживания и т.п.) и др.;

– требования к информационной и программной совместимости;

– требования к защите информации отдельно для АИС и предмета разработки;

– требования к первичному заполнению информационной базы (по необходимости);

– порядок выполнения работ по Проекту с указанием содержания работ и оценки объема работ (в часах);

– особые требования к проведению приемки работ (по необходимости);

– условия взаимодействия с другими проектами (по необходимости);

– другая необходимая информация.

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

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

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

– перечень автоматизируемых операций;

– создаваемые (модифицируемые) объекты АИС, их состав и правила функционирования;

– методология автоматизации для каждой операции и создаваемого (модифицируемого) объекта АИС;

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

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

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

– виды планируемых пользовательских инструкций (руководств);

– планирование встроенной справки для объектов АИС, создаваемых (модифицируемых) предметом разработки (Программным продуктом);

– планирование встроенной справки к АИС в целом.

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

– поддерживаемые форматы загрузки и выгрузки данных (требования к выгружаемым и загружаемым файлам);

– правила проведения загрузки и выгрузки данных (поля, отбор, группировка, сортировка таблиц при загрузке и выгрузке);

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

3.10. Требования к защите информации включают следующее:

– правила ограничения доступа к данным для пользователей АИС;

– использование средств криптографической защиты;

– использование защищенных каналов связи для АИС и др.

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

3.12. Техническое задание подписывают следующие лица:

– разработчик технического задания (автор);

– руководитель проекта (требуется согласование, если руководитель проекта не является разработчиком технического задания);

– исполнитель (требуется ознакомление, если исполнитель не является руководителем проекта или разработчиком технического задания);

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

4. Порядок выполнения работ и внедрения программных продуктов

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

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

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

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

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

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

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

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

– описание предмета разработки (Программного продукта) и всех его объектов;

– инструкции (руководства) пользователей АИС по эксплуатации предмета разработки (Программного продукта);

– историю изменений Программного продукта от версии к версии.

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

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

4.5. Тестирование, предшествующее приемке Программного продукта, проводит руководитель проекта, который проверяет:

– выполнение требований технических заданий;

– соблюдение общих принципов и требований к разработке, вытекающих из настоящего регламента;

– отсутствие ошибок в работе Программного продукта.

4.6. По итогам проведения тестирования руководитель проекта принимает одно из следующих решений:

– Программный продукт соответствует предъявляемым требованиям и готов к внедрению в АИС (в этом случае следующей процедурой является приемка Программного продукта);

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

– Программный продукт не соответствует предъявляемым требованиям и возвращается на доработку.

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

– заключение о соответствии Программного продукта предъявляемым требованиям;

– наличие необходимости в доработке Программного продукта;

– перечень необходимых исправлений с указанием нарушенных требований (при наличии нарушений);

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

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

4.9. В приемную комиссию могут включаться следующие лица:

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

– лица, заинтересованные во внедрении Программного продукта;

– представители руководства Предприятия.

Руководитель проекта и исполнители работ по проекту в состав приемной комиссии включаться не могут.

4.10. Приемная комиссия определяет пригодность Программного продукта для внедрения в АИС и соответствие функционала Программного продукта предъявляемым требованиям. По результатам приемки приемная комиссия принимает одно из следующих решений:

– Программный продукт допускается к использованию;

– Программный продукт не допускается к использованию.

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

4.12. Интеграция Программного продукта в работающую АИС до завершения процедуры приемки и составления акта внедрения не допускается. По окончании процедуры приемки внедрение Программного продукта в АИС осуществляет администратор АИС.

4.13. Документация проекта сшивается и сдается на ответственное хранение в отдел информационных технологий аппарата управления Предприятия. Хранение документации проекта осуществляется до завершения использования Программного продукта в деятельности Предприятия.

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

Кто такой разработчик ПО и чем занимается

Говоря простыми словами, разработчик ПО – это IT-специалист, который делает компьютерные программы разного назначения, например:

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

Обязанности программиста зависят от сферы, в которой он работает: создание корпоративного софта, видеоигр, программ для персональных компьютеров и т. д.

Кратко перечислим, чем обычно занимается разработчик ПО:

Что должен уметь специалист

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

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

Знания и навыки конкретного специалиста зависят от того, каким направлением разработки он занимается. Выделяют 3 специальности.

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

Разрабатывать динамичный, интерактивный интерфейс по макету, например, с использованием HTML, CSS и языка Javascript.
Применять принципы адаптивной верстки, чтобы приложение запускалось во всех операционных системах.
Понимать особенности UX/UI-дизайна, чтобы пользователям было удобно работать в программе.

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

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

Знает несколько языков (Javascript, Python, Java или др.), популярные библиотеки и фреймворки.
Работает в системе управления версиями Git, использует для сборки и развертывания приложения Docker или Kubernetes.
Понимает паттерны проектирования, а также гибкие методологии (например, Agile).

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

Востребованы ли разработчики программного обеспечения

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

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

Больше всего объявлений – от компаний Москвы, Санкт-Петербурга, Новосибирска, Нижнего Новгорода и Екатеринбурга. Явного преобладания по frontend или backend нет – представители обоих направлений одинаково востребованы. Чаще всего работодатели ищут специалистов с опытом около 3 лет.

Где работают по профессии

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

Отрасли, в которых чаще всего работают представители этой профессии:

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

К примеру, на данный момент разработчики ПО требуются в Транснефть, Газпром, РЖД, Лабораторию Касперского и Mail Group.

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

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

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

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

Постановка цели;
Ввод остатков в программу;
Обучение;
Доработка программы;
Написание документации;
Тестовая эксплуатация;
Промышленная эксплуатация.

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

Ввод остатков в программу

Ввод остатков в программу – это первый этап непосредственно вашей работы по внедрению программного продукта. И этот этап призван решить широкий перечень задач:

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

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

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

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

Обучение

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

Как это происходит?

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

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

Таким образом, я добиваюсь сразу трех целей:

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

Во время обучения очень важно наладить обратную связь

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

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

При обучении учитывайте гендерные различия сотрудников

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

Никакой снисходительности при обучении!

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

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

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

Напоминайте о том, что вы здесь – временно! Выполните проект и уйдете.

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

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

Обучите своего преемника из числа сотрудников компании.

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

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

Почему это хорошо?

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

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

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

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

Доработка программы

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

Я противник таких методов работы. Бизнес-консультант должен представлять интересы клиента. У вас общие цели: решить поставленные бизнес-задачи. И вы должны быть лояльны к интересам клиента.

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

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

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

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

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

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

Важно: бизнес-консультант, который работает с малым и средним бизнесом, должен быть неплохо знаком с программированием.

Лично я достаточно хорошо знаю 1С-программирование, также знаком с веб-программированием, в частности, работаю с Drupal и с другими CMS. В процессе работы с программистом вы должны четко поставить задачу специалисту, а потом грамотно протестировать выполненную работу перед тем, как ее принять и показать клиенту.

Никогда не давайте прямой доступ программисту к вашему клиенту!

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

Схема работы должна быть такой:

Вы получаете задачу от клиента – корректируете ее – передаете программисту техзадание.

Вы получаете работу от программиста – тестируете ее – передаете клиенту.

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

Консультант не должен злоупотреблять доверием клиента.

Написание документации

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

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

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

Что я предлагаю своим клиентам?

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

В комплект документации могут входить:

Описание процесса работы отдела;
План дня сотрудника;
Должностная инструкция;
Инструкция по работе с входящими / исходящими документами;
Инструкция по работе с программным продуктом;
Инструкции по работе с другими программами.

Лично я при создании подобной документации по максимум использую графику. Чаще всего, это графические нотации (IDEF 3, IDEF 0, Swim line и др.). Вы можете выбрать любой инструмент для создания таких графических инструкций, по своему вкусу. Главное – это результат. Кстати, избегайте упоминания нотаций, в которых вы будете делать описание бизнес-процесса, это информация не нужна клиенту.

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

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

АКЦИЯ ГОДА

Имидж профессионалов IT сферы в массовой культуре кардинально изменился за последние годы. Абсурдные стереотипы ушли в прошлое, а программисты стали настоящей элитой 2010-х.

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

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

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

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

Бизнес-аналитик

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

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

Но между целями клиента и функциями приложения лежит целая пропасть. Следовательно, бизнес-аналитик (сокращенно БA) должен точно определить, что хочет заказчик и что ему нужно.

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

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

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

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

Менеджер проекта

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

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

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

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

UI/UX дизайнер

Это тот человек, от которого идет большая часть креативности в проекте. Главная ответственность UI/UX дизайнера заключается в создании приятного интерфейса и отличного пользовательского опыта.

Дизайнер использует вайрфреймы, созданные клиентом или бизнес-аналитиком, чтобы “нарисовать” мокапы и создать дизайн интерфейса мобильного приложения (UI) согласно действующим гайдлайнам и трендам. Он также планирует пользовательский опыт, который сделает продукт удобным для использования.

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

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

Разработчики/программисты

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

Существуют различные уровни в команде разработчиков программного обеспечения, включающие junior, middle и senior уровни, которые зависят от опыта работы и уровня экспертизы.

Программисты также имеют различные области экспертизы, они пишут на различных языках и работают с различными платформами. Поэтому и существует такое “разнообразие” разработчиков, вовлеченных в один проект. Например, стандартный проект разработки мобильного приложения требует участия как минимум Android, iOS и backend-разработчиков.

QA (Quality Assurance) специалисты необходимы для каждого процесса разработки и обеспечения высокого качества продукта. Они тестируют его, проходят через все приложение и определяют баги и ошибки с последующим предоставлением отчета команде разработки, которая проводит их исправление.

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

Специалист по маркетингу

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

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

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

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

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

Читайте также: