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

Управление - Бизнес-процессы

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

Предисловие

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

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

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

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

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

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

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

Введение

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

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

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

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

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

Этап разработки трудоемкий и занимает, в идеале, несравнимо меньше времени по сравнению с этапом эксплуатации программного продукта.

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

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

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

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

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

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

  1. Менеджер продукта.
  2. Менеджер проекта.
  3. Разработчик (программист).
  4. Системный администратор, специалист в БД.
  5. Тестировщик.
  6. Служба поддержки пользователей.

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

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

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

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

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

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

Пример взаимодействия участников при создании проекта

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

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

- Привет, Виталий.

- Привет, Маша, - произнес программист, неохотно отрываясь от своих дел. Ему через 2 часа нужно отдать директору отчет, а до его готовности еще далеко.

- У меня есть идея. Ты можешь сделать, чтобы я могла печатать все документы не из 1С, а из Word’а.

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

- Ты меня не так понял, - не унималась Маша. – Мне это облегчит работу …

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

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

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

При этом возможны два варианта событий, удачный и сложный.

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

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

В офисе программиста появляется торжествующая Маша и с порога выпаливает:

- И все-таки ты сделаешь, что я тебе скажу.

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

- Видишь список? – спросил Машу программист. – В нем двенадцать записей, я тебя могу записать тринадцатой, писать?

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

Данный пример красноречиво иллюстрирует распространенное, но не эффективное взаимодействие сотрудников компании.

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

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

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

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

- Здравствуй, Владимир, проходи, располагайся, - ответил ему хозяин кабинета. – С чем пришел?

- У меня есть идея, как улучшить работу сотрудников компании.

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

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

Владимир завозился, доставая бумаги из папки.

- Я тут техническое задание накидал. Прикинул, что наш программист сможет все это реализовать.

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

- Я уже все расписал. Менеджер продукта я, менеджер проекта Вы.

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

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

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

На следующий день в кабинете заместителя директора.

- Владимир, заходи, - сказал хозяин кабинета. – Я рассмотрел твое предложение и принимаю его.

- Спасибо, Михаил Семенович, - сказал обрадованный Владимир.

- Итак, менеджеров мы выбрали. Разработчиком будет Виталий, системным администратором серверов назначим его же.

- Тестирование я сам проведу, службой поддержки будет Маша.

- Отлично, кто нам сделает проект системы?

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

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

- Я согласен, Михаил Семенович, - сказал Владимир, выходя из кабинета.

Возможности совмещения ролей

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

Менеджер продукта может также эффективно исполнить роль тестировщика, разработчик нередко совмещает роль системного администратора.

Это примеры удачного совмещения. Так же хорошо совмещаются роли тестировщика и службы поддержки.

Количество сотрудников в проекте может сокращаться до трех человек. Главное правильно совместить роли не понизив эффективность работы коллектива.

Классический пример, когда совмещаются роли: Менеджер продукта-Тестировщик, Менеджер проекта-Разработчик, Системный администратор-Служба поддержки.

Роли Менеджера продукта и Менеджера проекта совмещать нельзя ни в коем случае! Из взаимодействия этих ролей как раз и рождается движение к выполнению проекта. Как в диалектике единство и борьба противоположностей.

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

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

Из всего этого следуют выводы:

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

См. также

Комментарии
1. Sergei (kauksi) 195 13.03.17 15:13 Сейчас в теме
Щас придет Tutitutu и расскажет вам success story как надо писать программу для торговли.
2. kolya_tlt kolya_tlt (kolya_tlt) 10 13.03.17 15:24 Сейчас в теме
букв много, а в чем собственно суть?
3. Евгений Бочкарев (Ликреонский) 75 13.03.17 15:38 Сейчас в теме
(2)Суть в том, что многие компании совершают ошибки при организации процесса разработки и внедрения программы. Я предлагаю методику, чтоб этих ошибок избежать (и наделать других :) ).
4. kolya_tlt kolya_tlt (kolya_tlt) 10 13.03.17 15:42 Сейчас в теме
(3) так я спрашиваю где ваша методика? вы написали введение, описали роли и какой-то мифический пример. методика в статье отсутствует.
5. Евгений Бочкарев (Ликреонский) 75 13.03.17 15:50 Сейчас в теме
(4)В ролях и есть суть статьи. Если интересуют подробности рекомендую MSF.
6. Виталий Попов (Сурикат) 135 14.03.17 13:08 Сейчас в теме
За стиль написания плюс =)
А конкретно по сабжу обычно не проблема в подходе, а проблема в квалификации и ответственности людей исполняющих роли.
Просто сотрудник компании не может применить на себя роль менеджера продукта, элементарно не хватает квалификации или желания, а иногда и того и того.
В итоге программист аки Шива выполняет все эти роли. А если еще это и торговая компания, как написано в заголовке, то зачастую это просто огромный поток мелких задач, которые никак не запихнешь в рамки проекта.
Ликреонский; +1 Ответить 1
7. Евгений Бочкарев (Ликреонский) 75 14.03.17 13:18 Сейчас в теме
(6)Спасибо за комплименты.
Согласен, в основном мелкие доработки и некомпетентность, поэтому я делаю попытки объяснить работодателям и не только, что развитие не в мелких доработках, а серьезных проектах.
Когда программист аки Шива хорошего мало получается, в лучшем случае красивый код программы.
8. Роберт В е р т и н с к и й (v3rter) 14.03.17 14:11 Сейчас в теме
Менеджер продукта = Заказчик (начальник не IT-отдела)
Менеджер проекта = Подрядчик (начальник IT-отдела)

Разработчик сам себе не Тестировщик.
При совмещении ролей Заказчика и Подрядчика появляется соблазн сократить функциональность проекта. Логично.

Кстати, кто из них будет аналитик (архитектор)? Тот самый, кто из невнятных пожеланий Заказчика построит внятное техзадание Разработчику с учётом перспектив развития пожеланий, возможностей железа, возможностей Разработчика и имеющихся сроков и ресурсов?

Системный администратор, как самый продуманный и информированный?
9. Евгений Бочкарев (Ликреонский) 75 14.03.17 14:18 Сейчас в теме
(8)Аналитику видимо уготована будет роль тестировщика или службы поддержки. На этапе проектирования аналитик поможет менеджерам создать проект, как внешний специалист.
10. Роберт В е р т и н с к и й (v3rter) 14.03.17 17:59 Сейчас в теме
В статье хорошо расписано взаимодействие исполнителей. А вот кто за них будет додумывать и шлифовать детали, осталось за кадром. Аналитиком чаще всего оказывается "коллективный разум" - с хорошим результатом, но по срокам на порядок медленнее отдельного живого человека ) Почему я зацепился за эту тему - вклад аналитика в общий успех проекта порой бывает не просто большим, а решающим. Интересно было бы проследить его деятельность общей схеме, потому как аналитику приходится контролировать процесс на всех этапах, не только до и после запуска. Думаю, лучшее применение аналитика - менеджер проекта (подрядчик) или его помощник.
Ликреонский; +1 Ответить 1
11. Евгений Бочкарев (Ликреонский) 75 14.03.17 23:48 Сейчас в теме
(10)Аналитик может выступать и менеджером продукта. Дело в том, что в статье отсутствует аналитик, это связано с моим опытом разработки проектов, где не был отдельно выделен аналитик.
На мой взгляд, роль аналитика участвует в создании проекта, именно в том, что идет за техзаданием, для того чтобы он обозначился нужно в другом масштабе посмотреть на процесс.
Статья совершенно не отвечает на животрепещущий вопрос: Как создать проект? А жаль.
Уверяю Вас, если бы я знал на этот вопрос точный ответ, я бы не рассказал, а жил бы богато и статьи бы не писал. :)
Коррелирует с вашим утверждением:
вклад аналитика в общий успех проекта порой бывает не просто большим, а решающим
. При удачном проекте успех почти неизбежен, при промахах провал гарантирован.
аналитику приходится контролировать процесс на всех этапах, не только до и после запуска
Вот тут как раз просматривается роль в службе поддержки и тестирования.
И согласен в Вами, что роль менеджера проекта вполне подойдет аналитику. Получается аналитик может быть кем угодно, но скорее всего не разработчиком. Хотя, почему нет? Я же работаю.
И системным администратором, при наличии соответствующих компетенций тоже может быть.
В общем, умный человек может исполнить любую роль, лишь бы не лень было. :))
12. Дмитрий Перевалов (DimeATB) 17.03.17 15:42 Сейчас в теме
В определении роли менеджера продукта есть такое предложение: "В задачи и обязанности этой роли входит определение потребительских свойств проекта и функции, выполняемые программным продуктом при эксплуатации".

Что есть такое "потребительских свойств проекта"? Я впервые вижу такой термин.
13. Евгений Бочкарев (Ликреонский) 75 17.03.17 21:34 Сейчас в теме
Менеджер продукта определяет как будет выглядеть программный продукт и что он будет делать. Программный продукт не отличается от промышленных изделий и обладает потребительскими свойствами, т.к. его пользователи потребляют используя в своих целях.
На этапе постановки технического задания МП определяет свойства ради которых и затрачивается столько усилий и интеллектуальных возможностей.
14. Дмитрий Перевалов (DimeATB) 17.03.17 22:14 Сейчас в теме
Автору спасибо!

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

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

Отдельных тестеров встречал очень редко. Чаще программист тестит код на отсутствие критических и не документированных ошибок (например, появляется системная ошибка или выскакивает непонятное для пользователя сообщение). Система показывает только те сообщения пользователю, которые задокументированы и продиктованы требованиями бизнес-аналитика (например, документ сообщает, что не достаточно материала для списания со склада в производство; всяких error 40001 SQL nativ... быть не должно). Тестит так же не функциональные бизнес-требования (например, требование чтобы отчёт формировался не более пяти секунд). Тестит доступность объектов по ролям и интерфейсам. Функционал тестят заказчики системы по тест кейсам, которые они согласовали с бизнес-аналитиком.

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

Беда в том, что на небольших предприятиях программист совмещает более чем две роли (архитектор и бизнес-аналитик - тоже он).
А поскольку небольших предприятий всегда больше чем крупных, то стереотип программиста на все руки мастера прочно въедается в сознание как заказчиков, так и исполнителей, что приводит к двум крайностям - неадекватное видение обязанностей программиста со стороны заказчиков и комплекс неполноценности у программиста. Так рождаются вот такие списки направлений работы программиста 1С: http://infostart.ru/public/160160/ Хотя в других областях программирования эти направления разделены по разным специалистам и разработчик там просто разработчик.
Сурикат; support; vitaliy1911; +3 Ответить 1
15. Дмитрий Перевалов (DimeATB) 17.03.17 22:18 Сейчас в теме
(13) Тогда наверное Вы хотели написать "потребительских свойств продукта", а не "проекта"?
Я "потребительские свойства проекта" за всю практику не встречал нигде. Но всё течёт и меняется, может это новое веяние какое-то о котором я ещё не читал.
16. Евгений Бочкарев (Ликреонский) 75 18.03.17 14:33 Сейчас в теме
(15)Слово "проект" может быть использовано в нескольких значениях, как описание того что нужно сделать и эксплуатировать в дальнейшем, так и совокупность действий и результатов. Я понимаю это слово в нескольких значениях, но специально для Вас признаю, что точнее использовать слово продукт и в контексте статьи это точно слово продукт.
Статья отражает очень маленькую часть проблем при разработке ПО, поэтому во многих случаях придется использовать именно "проект" как совокупность действий, людей, документации. И в данном контексте вполне будет уместно потребительские свойства проекта. Как и уместно: жизненный цикл проекта.
Но за точность спасибо, может кому пригодится.
17. Евгений Бочкарев (Ликреонский) 75 18.03.17 14:44 Сейчас в теме
(14) Масштаб проекта неважен, просто увеличится количество исполнителей. Данная система применима по крайней мере в торговый предприятиях, во всех их системах деятельности, включая АХО.
Владелец системы (продукта)
в терминологии статьи сильно напоминает Менеджера продукта.
Я думаю существует огромное количество структур для разработки, я стараюсь найти простую, но эффективную. Проверяю, транслирую. За мои более 20 лет опыта разработки ПО, эта терминология, на данном этапе развития информационных систем России, оказывается наиболее простой и эффективной.
Оставьте свое сообщение