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

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

Полностью согласен. Это я просто "сгустил краски", а в ситуациях всегда есть полутона, которые отличаются от того что предписывают правила и теория.

Анатолий Курочкин пишет:
И удивлён жалобой разработчиков на отсутствие коммуникаций с архитектором. Ну так не бывает. Архитектор является участником команды с самого начала, без него невозможно реализовать ИТ-проект, невозможно сдать его заказчкку. Ведь в ТЗ все не пропишешь, не пропишешь, какие механизмы  будут реализованы в том или ином функцицонале. Тем более, что пользователь может совершенно не разбираться в работе внутренностей системы.

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

Вероятно дело в том, что Архитектор один(где наберешься такое количество таких специалистов?), а продуктов и команд может быть много.

В Тойоте например Архитектора назвали Главным инженером продукта и он отвечал за один конкретный продукт от стадии проектирования до производства и на производстве!

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

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

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

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

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

Борис Кондрабаев пишет:
Проблемы с Архитектором я слышал не в Тиньков, а в других, в том числе чрезвычайно успешных компаниях!

Вероятно дело в том, что Архитектор один(где наберешься такое количество таких специалистов?), а продуктов и команд может быть много.

В Тойоте например Архитектора назвали Главным инженером продукта и он отвечал за один конкретный продукт от стадии проектирования до производства и на производстве!

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

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

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

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

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

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

Я уже высказывал предположение что у Вас все в порядке! Может поделитесь опытом взаимодействия разработчиков и пользователей?

Вероятно это может быть полезным для других, с другим опытом!

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

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

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

Это не закон природы. Детали зависят от отрасли и размеров организации. Кое-что видно в балансе предприятия и других документах отчетности.

Борис Кондрабаев пишет:
Алгоритмы, как в бизнесе, так и в военном деле аналогичны.

Что Вы имете в виду? Процессы в бизнесе и уставы в армии? Или, к примеру, логистику в армии и логистику в бизнесе? Но звучит немного загадочно.

Евгений Равич пишет:
Что Вы имете в виду? Процессы в бизнесе и уставы в армии? Или, к примеру, логистику в армии и логистику в бизнесе? Но звучит немного загадочно.

Я про уставы ничего не говорил. Загадочно получается когда фантазируешь над тем чего нет.

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

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

Странно, что зная азы экономики есть "слепые зоны"?

Хотя чего тут странного, если экономика стала уже фрикономикой. Чтобы снизить уровень иллюзий и заблуждений есть настоящая экономика и статистика, об этом можно почитать или перечитать у Стивена Левитта!:)

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

Евгений Равич пишет:
Что Вы имете в виду? Процессы в бизнесе и уставы в армии? Или, к примеру, логистику в армии и логистику в бизнесе? Но звучит немного загадочно.

Я про уставы ничего не говорил. Загадочно получается когда фантазируешь над тем чего нет.

Тогда что Вы называете алгоритмами? Это слово имеет вполне определённое значение.

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

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

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

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

Но мы говорим о прогнозе продаж, то есть - обычно - о периоде от года до трёх лет. 

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

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

Я уже высказывал предположение что у Вас все в порядке! Может поделитесь опытом взаимодействия разработчиков и пользователей?

Вероятно это может быть полезным для других, с другим опытом!

Так я бы хотел узнать, что у автора топика не так. А у меня, как и всех разработчиков. Есть проблемы, кторые решаются.

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

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

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

Обменялись взглядами - на этом я останавливаюсь.

Увидимся когда увидимся!:)

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

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

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

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

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

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

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

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

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

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

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

Евгений Равич пишет:
Какой подход в этой дискуссии представляете Вы - если Вы так действительно считаете - для меня загадка.

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

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

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

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

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

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

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

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

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

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

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

При этом в основе лежит тот же план основанный на гипотезах!

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

Собственно управление это и есть менеджмент(можете посмотреть в словаре:)), а другой менеджмент больше основан на командовании и контроле!

Так понятней? 

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

Не стоит использовать "тона, когда в жизни не просто полутона, а разноцветие и многополярность"!:)

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

Это еще одно отличие того подхода который я применяю!:)

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

Евгений Равич пишет:
Какой подход в этой дискуссии представляете Вы - если Вы так действительно считаете - для меня загадка.

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

Это очень лестно! Но откуда Вы знаете, как я действую?

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

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

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

Допустим. И эти доказательства как-то можно получить в обозримое время.

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

А вот такого не бывает. Фантазии - это фантазии, а не гипотезы.

Фантазии не нуждаются в доказательствах - другой жанр. Нет смысла употреблять одно слово вместо другого. Оставим фантазии фантазёрам.

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

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

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

То есть продажи за период оказались ниже ожидаемых, а складские запасы - выше. Или часть мощностей можно не задействовать. Так?

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

И многое зависит от отрасли. Например, снижение объема перевозок или выработки электроэнергии.

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

Ужасно. Но ничего особенного.  Бывает. Важно понимать, ошибки ли это планирования, разовое явление на рынке или новый тренд. Азы маркетинга.

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

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

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

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

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

А что Вам показывает этот пример?

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

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

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

Если убрать прилагательные - за счет чего такое можно реализовать? И кто знает и устанавливает эти пределы?

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

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

При этом в основе лежит тот же план основанный на гипотезах!

Такой подход мне не встречался. Финансовые и производственные планы не берутся из воздуха и не возникают сами по себе. И обычно многократно обсуждаются.

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

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

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

Change Management - отдельная тема, там всё начинается с целей планируемых изменений.

Собственно управление это и есть менеджмент(можете посмотреть в словаре:)), а другой менеджмент больше основан на командовании и контроле!

Так понятней?

Оставьте какое-то одно слово, которое Вам больше нравится - слишком много синонимов.

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

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

Контекст безусловно важен. Но я так и не понимаю, что именно Вы вкладываете в слово "алгоритм". Честно.

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

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

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