Проблема взаимопонимания между разработчиками ПО и пользователями ПО

Борис Кондрабаев пишет:

Евгений Равич пишет:
Это очень лестно! Но откуда Вы знаете, как я действую?

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

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

Понял. Любопытно.

А когда Вы подводите итоги финансового года? 

Эрнст Мальцев пишет:

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

1. Джеф Паттон, "Пользовательские истории. Искусство гибкой разработки ПО" (любимое издательство O'Reilly; здесь - издательство "Питер").

2. Классика: Карл Виггерс, Джой Битти "Разработка требований к программному обеспечению" (Microsoft).

Что скажете? Какие мнения по данным изданиям с точки зрения заказчиков и/или разработчиков?

 

Полностью поддерживаю. 

Karl Wiegers уже много лет улучшает свою классическую книгу. Он достаточно активен в дискуссиях, и мне обычно интересно следить за ходом его мысли.

Есть несколько больших тем, близких к разработке ПО, но не буквально о разработке. Нужно знать, чем человек занимается - а хороших книг и статей много.

Анатолий Курочкин пишет:
И удивлён жалобой разработчиков на отсутствие коммуникаций с архитектором. Ну так не бывает.

Верно. Так не бывает. Иначе архитектор просто не нужен.

Евгений Равич пишет:
А когда Вы подводите итоги финансового года? 

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

Евгений Равич пишет:
Оставьте какое-то одно слово, которое Вам больше нравится - слишком много синонимов. И можно начать прямо с Файоля - у него блестяще перечислено, что должен делать менеджер, включая и то, что в Вашем списке. 

Возьмем как Вы выразились азы маркетинга, с точки зрения Файоля, а если быть более точным, то того что он считает должен делать менеджер!

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

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

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

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

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

При этом я верю, что даже в таком подходе у Руководителя много проблем, забот и работ.

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

Я спокойно и филосовски отношусь к тому, что происходит вокруг. Как например гласит Дзен "падает снег и каждая снежинка на своем месте!", также и Руководители в сложившейся ситуации - на своем месте!

И в то же время я искренне высказываюсь о том, что можно действовать по другому.

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

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

Что касается аналогичных доказательств, то есть шутливая и в то же воремя филосовская метафора Григория Горина, вополощенная им в Бароне Мунхгаузене и великолепно исполненная Олегом Янковским.

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

Борис Кондрабаев пишет:
Любой план - это гипотезы, основанные на каких то данных.

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

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

Мне очень трудно согласится с вашими толкованиями, Борис. Обратил внимание, что ТЗ для вас оторвано от пользователей. А план - это гипотеза на предположениях и догадках. 

Глубоко убеждён, что это не так. План - это в первую очередь расчёт, а ТЗ - это описание  требований пользователя. 

Борис Кондрабаев пишет:

Николай Зоин пишет:
Это самая обычная практика! Так и делается любое ТЗ, если только ТЗ делабют не профаны. Именно так! Или матрица, или простые чек-листы. А как иначе? Фантастика этажом ниже )))

Для широты взгляда, может поделитесь своим опытом по матрице или чек-листу?

Зачем? Это всё очень простые вещи для любого бизнес-аналитика. 

Анатолий Курочкин пишет:
Мне очень трудно согласится с вашими толкованиями, Борис. Обратил внимание, что ТЗ для вас оторвано от пользователей. А план - это гипотеза на предположениях и догадках. 

Про ТЗ мнение ошибочное относительно моей личности.

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

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

Николай Зоин пишет:
Зачем? Это всё очень простые вещи для любого бизнес-аналитика. 

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

Если поделитесь знаниями и опытом что и как делать по матрицам и чек-листам, то это существенно снизит проблему взаимопонимания по обсуждаемой теме!

Борис Кондрабаев пишет:

Евгений Равич пишет:
А когда Вы подводите итоги финансового года? 

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

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

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

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

Но сама собой отчетность не формируется. Вспомним, что корпоративные системы в производственных организациях обычно состоят из нескольких функциональных модулей - ERP, CRM, MRP, склад, финансы, юридические системы, бухгалтерия и пр. и пр.. Что-то из перечисленного интегрировано, что-то используется отдельно. 

Так менеджер узнаёт о происходящем по мере необходимости.

например в самолетостроении мы точно знаем, что самолетов нужно много, то есть на них есть платежеспособный спрос!

В данный момент - да.

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

Между собой - имеется в виду с конкурентами? Да, производственники знают, что чем больше они сделают, тем короче станет очередь. Хотя какие-то модели больше не производят из-за отсутствия спроса - Airbus A380, к примеру.

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

Пока это выяснили только Вы. Могут и уволить, но за другое.

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

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

См. выше. Предыдущий план уже не интересен. Как и то, сделал ли он больше или меньше. Он должен сделать то, что запланировано, а всё остальное обсуждается отдельно. Вы же, вроде бы, против бессмысленного расхода корпоративных ресурсов?

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

Обманывать нехорошо. А в бизнесе - фатально.

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

Что, на Ваш взгляд, хуже: пообещать и не сделать, или обещать и сделать?

Например, пообещать поставить крупную партию лекарств, на которые рассчитывают люди, подписать контракт, подтверждать сроки поставки - и не поставить?

Правило совсем простое: можешь - сделай, не можешь - не обещай. 

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

Тогда это не кризис, а нормальное состояние. Хотя в чём именно этот кризис заключается, Вы не пояснили.

Анатолий Курочкин пишет:

Борис Кондрабаев пишет:
Любой план - это гипотезы, основанные на каких то данных.

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

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

Мне очень трудно согласится с вашими толкованиями, Борис. Обратил внимание, что ТЗ для вас оторвано от пользователей. А план - это гипотеза на предположениях и догадках. 

Глубоко убеждён, что это не так. План - это в первую очередь расчёт, а ТЗ - это описание  требований пользователя. 

Если мы говорим о ТЗ, то всегда можно сослаться на полное название документа ("Техническое задание на ...") и соответствующий стандарт, в котором описано его содержание, порядок подготовки, предществующие документы и другие важные детали. Или мы сразу говорим об отсутствии требования заказчика по использованию ГОСТ.

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

Николай Зоин пишет:

Борис Кондрабаев пишет:
Мне понравилось в Тиньков, что они разработали чек-лист для ТЗ и пока не соберут по нему информацию не берут в разработку! На мой взгляд очень удобно, снимает много проблем и в Духе Тойоты!:)

Это самая обычная практика! Так и делается любое ТЗ, если только ТЗ делабют не профаны. Именно так! Или матрица, или простые чек-листы. А как иначе? Фантастика этажом ниже )))

Или можно посмотреть ГОСТ соответствующей серии. Чек-лист там внутри. Заодно сказано, что такое "ТЗ".

Евгений Равич пишет:
Но менеджмента без плана и результата не бывает.

А зачем вообще говоря нужен план?
Результат -- понятно, все ради него. А план-то зачем?

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

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

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

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

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

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

Евгений Равич пишет:

Эрнст Мальцев пишет:

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

1. Джеф Паттон, "Пользовательские истории. Искусство гибкой разработки ПО" (любимое издательство O'Reilly; здесь - издательство "Питер").

2. Классика: Карл Виггерс, Джой Битти "Разработка требований к программному обеспечению" (Microsoft).

Что скажете? Какие мнения по данным изданиям с точки зрения заказчиков и/или разработчиков?

 

Полностью поддерживаю. 

Karl Wiegers уже много лет улучшает свою классическую книгу. Он достаточно активен в дискуссиях, и мне обычно интересно следить за ходом его мысли.

Есть несколько больших тем, близких к разработке ПО, но не буквально о разработке. Нужно знать, чем человек занимается - а хороших книг и статей много.

К вопросу о ПО, книгах и чек-листах.

У Karl Wiegers и его соавторов есть вторая линия книг о требованиях к ПО (Essentials...) и хорошие ресурсы на эту тему. 

https://softwarereqs.com

Сергей Средний пишет:

Евгений Равич пишет:
Но менеджмента без плана и результата не бывает.

А зачем вообще говоря нужен план?
Результат -- понятно, все ради него. А план-то зачем?

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

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

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

Позвольте уточнить - Вы в какой области работаете в данный момент? 

Евгений Равич пишет:
Позвольте уточнить - Вы в какой области работаете в данный момент? 

Не, не позволю. По существу вопроса есть что? Давайте к делу пожалуйста.