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

13.03.17

Управление проектом

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

Предисловие

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

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

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

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

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

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также

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

Кейсы проектов Бесплатно (free)

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

20.12.2023    2778    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14308    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5854    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    4704    0    andironenko    2    

31

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

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

27.12.2022    2749    0    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

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

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4188    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

09.09.2022    10678    0    biimmap    79    

75

Как донести здравый смысл до заказчика. Инструменты архитектора

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

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

05.08.2022    13094    0    Evil Beaver    17    

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

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

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

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

Что есть такое "потребительских свойств проекта"? Я впервые вижу такой термин.
13. Ликреонский 238 17.03.17 21:34 Сейчас в теме
Менеджер продукта определяет как будет выглядеть программный продукт и что он будет делать. Программный продукт не отличается от промышленных изделий и обладает потребительскими свойствами, т.к. его пользователи потребляют используя в своих целях.
На этапе постановки технического задания МП определяет свойства ради которых и затрачивается столько усилий и интеллектуальных возможностей.
15. DmitriyPerevalov 17.03.17 22:18 Сейчас в теме
(13) Тогда наверное Вы хотели написать "потребительских свойств продукта", а не "проекта"?
Я "потребительские свойства проекта" за всю практику не встречал нигде. Но всё течёт и меняется, может это новое веяние какое-то о котором я ещё не читал.
16. Ликреонский 238 18.03.17 14:33 Сейчас в теме
(15)Слово "проект" может быть использовано в нескольких значениях, как описание того что нужно сделать и эксплуатировать в дальнейшем, так и совокупность действий и результатов. Я понимаю это слово в нескольких значениях, но специально для Вас признаю, что точнее использовать слово продукт и в контексте статьи это точно слово продукт.
Статья отражает очень маленькую часть проблем при разработке ПО, поэтому во многих случаях придется использовать именно "проект" как совокупность действий, людей, документации. И в данном контексте вполне будет уместно потребительские свойства проекта. Как и уместно: жизненный цикл проекта.
Но за точность спасибо, может кому пригодится.
14. DmitriyPerevalov 17.03.17 22:14 Сейчас в теме
Автору спасибо!

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

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

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

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

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