Успешная разработка программного обеспечения в торговых организациях
Автоматизация бухгалтерского учета
Разработки для оптимизации управления и новейшие отчеты и обработки программ
Автоматизация бухгалтерского учета
Разработки для оптимизации управления и новейшие отчеты и обработки программ
Щас придет Tutitutu и расскажет вам success story как надо писать программу для торговли.
букв много, а в чем собственно суть?
(2)Суть в том, что многие компании совершают ошибки при организации процесса разработки и внедрения программы. Я предлагаю методику, чтоб этих ошибок избежать (и наделать других 🙂 ).
(3) так я спрашиваю где ваша методика? вы написали введение, описали роли и какой-то мифический пример. методика в статье отсутствует.
(4)В ролях и есть суть статьи. Если интересуют подробности рекомендую MSF.
За стиль написания плюс =)
А конкретно по сабжу обычно не проблема в подходе, а проблема в квалификации и ответственности людей исполняющих роли.
Просто сотрудник компании не может применить на себя роль менеджера продукта, элементарно не хватает квалификации или желания, а иногда и того и того.
В итоге программист аки Шива выполняет все эти роли. А если еще это и торговая компания, как написано в заголовке, то зачастую это просто огромный поток мелких задач, которые никак не запихнешь в рамки проекта.
(6)Спасибо за комплименты.
Согласен, в основном мелкие доработки и некомпетентность, поэтому я делаю попытки объяснить работодателям и не только, что развитие не в мелких доработках, а серьезных проектах.
Когда программист аки Шива хорошего мало получается, в лучшем случае красивый код программы.
Менеджер продукта = Заказчик (начальник не IT-отдела)
Менеджер проекта = Подрядчик (начальник IT-отдела)
Разработчик сам себе не Тестировщик.
При совмещении ролей Заказчика и Подрядчика появляется соблазн сократить функциональность проекта. Логично.
Кстати, кто из них будет аналитик (архитектор)? Тот самый, кто из невнятных пожеланий Заказчика построит внятное техзадание Разработчику с учётом перспектив развития пожеланий, возможностей железа, возможностей Разработчика и имеющихся сроков и ресурсов?
Системный администратор, как самый продуманный и информированный?
(8)Аналитику видимо уготована будет роль тестировщика или службы поддержки. На этапе проектирования аналитик поможет менеджерам создать проект, как внешний специалист.
В статье хорошо расписано взаимодействие исполнителей. А вот кто за них будет додумывать и шлифовать детали, осталось за кадром. Аналитиком чаще всего оказывается «коллективный разум» — с хорошим результатом, но по срокам на порядок медленнее отдельного живого человека ) Почему я зацепился за эту тему — вклад аналитика в общий успех проекта порой бывает не просто большим, а решающим. Интересно было бы проследить его деятельность общей схеме, потому как аналитику приходится контролировать процесс на всех этапах, не только до и после запуска. Думаю, лучшее применение аналитика — менеджер проекта (подрядчик) или его помощник.
(10)Аналитик может выступать и менеджером продукта. Дело в том, что в статье отсутствует аналитик, это связано с моим опытом разработки проектов, где не был отдельно выделен аналитик.
На мой взгляд, роль аналитика участвует в создании проекта, именно в том, что идет за техзаданием, для того чтобы он обозначился нужно в другом масштабе посмотреть на процесс.
Статья совершенно не отвечает на животрепещущий вопрос: Как создать проект? А жаль.
Уверяю Вас, если бы я знал на этот вопрос точный ответ, я бы не рассказал, а жил бы богато и статьи бы не писал. 🙂
Коррелирует с вашим утверждением:
. При удачном проекте успех почти неизбежен, при промахах провал гарантирован.
Вот тут как раз просматривается роль в службе поддержки и тестирования.
И согласен в Вами, что роль менеджера проекта вполне подойдет аналитику. Получается аналитик может быть кем угодно, но скорее всего не разработчиком. Хотя, почему нет? Я же работаю.
И системным администратором, при наличии соответствующих компетенций тоже может быть.
В общем, умный человек может исполнить любую роль, лишь бы не лень было. :))
В определении роли менеджера продукта есть такое предложение: «В задачи и обязанности этой роли входит определение потребительских свойств проекта и функции, выполняемые программным продуктом при эксплуатации».
Что есть такое «потребительских свойств проекта»? Я впервые вижу такой термин.
Менеджер продукта определяет как будет выглядеть программный продукт и что он будет делать. Программный продукт не отличается от промышленных изделий и обладает потребительскими свойствами, т.к. его пользователи потребляют используя в своих целях.
На этапе постановки технического задания МП определяет свойства ради которых и затрачивается столько усилий и интеллектуальных возможностей.
(13) Тогда наверное Вы хотели написать «потребительских свойств продукта», а не «проекта»?
Я «потребительские свойства проекта» за всю практику не встречал нигде. Но всё течёт и меняется, может это новое веяние какое-то о котором я ещё не читал.
(15)Слово «проект» может быть использовано в нескольких значениях, как описание того что нужно сделать и эксплуатировать в дальнейшем, так и совокупность действий и результатов. Я понимаю это слово в нескольких значениях, но специально для Вас признаю, что точнее использовать слово продукт и в контексте статьи это точно слово продукт.
Статья отражает очень маленькую часть проблем при разработке ПО, поэтому во многих случаях придется использовать именно «проект» как совокупность действий, людей, документации. И в данном контексте вполне будет уместно потребительские свойства проекта. Как и уместно: жизненный цикл проекта.
Но за точность спасибо, может кому пригодится.
(14) Масштаб проекта неважен, просто увеличится количество исполнителей. Данная система применима по крайней мере в торговый предприятиях, во всех их системах деятельности, включая АХО.
в терминологии статьи сильно напоминает Менеджера продукта.
Я думаю существует огромное количество структур для разработки, я стараюсь найти простую, но эффективную. Проверяю, транслирую. За мои более 20 лет опыта разработки ПО, эта терминология, на данном этапе развития информационных систем России, оказывается наиболее простой и эффективной.