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

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

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

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

И особенно как эти наработки применяются по ситуации в реальной игре.

Спорить по поводу терминов в научной организации труда считается потерями времени.

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

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

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

Как видите я сам себе сейчас противоречу по применению научной точки зрения! Как Вам такая научная организация труда?!:)

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

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

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

Именно так. Наработанная кем-то практика.

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

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

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

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

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

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

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

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

Как видите я сам себе сейчас противоречу по применению научной точки зрения! Как Вам такая научная организация труда?!:)

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

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

Многие теории рождаются на основе анализа реального опыта, например Деминг и его последователи постарались построить свою базовую теорию на основе статистики заводов Форда.

Где то читал и заметил любопытный нюанс, в психологии на основе одних и тех же клинических опытов(статистики) совершаются совершенно разные открытия и создаются новые теории!:)

К тому же в последнее время все более популярной стала коммерческая тайна, под которую подводят даже то что не должно было бы ей быть!:)

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

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

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

С одной стороны можно считать что есть разные стороны со своими интересами.

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

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

Основой любой науки является статистика!

Если веритить исследованиям, то чем более авторитетны и образованы люди, тем больше они ошибаются в прогнозах, по сравнению с другими живыми и абсолютно не образованными существами!:)

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

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

Эта опасность существует не только для "высоких" руководителей, но и для простых исполнителей! Знание этого тоже является научной организацией труда.

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

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

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

Здесь правда тоже есть опасность нарваться на креативщиков, которые могут смодерировать столько идей(такие у них правила и теория=наука), что голова кругом пойдет!:)

Я обратил внимание, что на многих уровнях существует тренд! Большинство чиновников и руководителей ждут, что им принесут готовые "советы и рецепты", а они их рассмотрят и примут решение что с ними делать.

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

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

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

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

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

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

Есть надежда, что есть технари на серийном производстве оборонных заказов! Но кто свяжет гражданку и оборонку? К тому же разработчики наверняка считают себя умнее остальных и их может не интересовать мнение производственников?

Вероятно что так же может происходить и в ИТ сфере - что и является одной из причин проблем взаимопонимания между разработчиками и пользователями таких разработок!

Борис Кондрабаев пишет:
Многие теории рождаются на основе анализа реального опыта

Хотелось бы, чтобы все.

Борис Кондрабаев пишет:
Если модератор занимается только этим, то вряд ли получится найти что то простое и подходящее

Модератор ничего не ищет. Его работа не в этом.

Борис Кондрабаев пишет:
Основой любой науки является статистика!

Скажем, данные. Данные наблюдений, расчеты, экспериментальные данные, работа с источниками, поиск новых данных, если имеющихся не хватает. Зависит от предмета науки.

Борис Кондрабаев пишет:
Именно поэтому задача консультанта-модератора навести

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

Консультант-модератор для меня - слесарь-гинеколог, как говорили в старину.

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

Бывает - и достаточно часто. Именно специалистов в конкретных вопросах, обладающих нужными в данный момент компетенциями. Обычно помогает.

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

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

Борис Кондрабаев пишет:
Вероятно что так же может происходить и в ИТ сфере - что и является одной из причин проблем взаимопонимания между разработчиками и пользователями таких разработок!

Я в этом сомневаюсь. В разработке ПО много своих проблем.

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

Дело не в терминах и названиях - подходящие действия я привел.

Евгений Равич пишет:
Я в этом сомневаюсь. В разработке ПО много своих проблем.

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

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

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

Дело не в терминах и названиях - подходящие действия я привел.

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

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

Евгений Равич пишет:
Я в этом сомневаюсь. В разработке ПО много своих проблем.

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

Проблемы - это намного больше, чем нюансы. В каждой отрасли они свои.

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

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

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

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

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

Один - это действовать не раздумая так как прописано в приказе, что очень похоже на Канбан многих японских компаний(не путать с Канбаном в ИТ-сфере, где произошла подмена понятий).

Второй - это действовать по обстоятельствам, где можно различить Дух приказа и Букву приказа, от которой как раз можно отклоняться чтобы самым эффективным образом выполнить Дух приказа!:) 

Вероятно, что после того как они натренировались таким коллективным взаимодействиям, то стали считать это своим "секретным оружием"!:)

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

Мне лично как раз интересно принимать участие в разработке одного шага, первого для каждой проблемы или задачи!:) Ключевое - я не ищу работу, а ищу интересное для меня занятие с интересными мне людьми!

Хоть без обязательств с обеих сторон, но как соучастник. Термины могут быть разные: консультант, модератор, советник(кстати в табели о рангах была прописана целая иерархия советников:)), "штурмовик"(мозговой штурм):)

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

Я не питаю иллюзий - партнерство может как получиться, так и не получиться!Особенно если работать с теми кто считает себя самыми умными и авторитетными - "в полный стакан воды не нальешь"(с):(

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

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

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

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

Не совсем так. Есть уставы, есть приказы. Есть практика и опыт.

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

Борис Кондрабаев пишет:
Вероятно, что одно из объяснений этой проблемы состоит в том, что пользователям нужно ПО как можно проще, а разработчикам нужно постоянно и периодически отчитываться о новых разработках(основе зарплаты).

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

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

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

Вероятно что так же может происходить и в ИТ сфере - что и является одной из причин проблем взаимопонимания между разработчиками и пользователями таких разработок!

Разработчики не считают себя умнее других. Им не до этого, у них есть ТЗ, которое утверждает заказчик. Для постановки на производство существует целый набор обязательных процедур и регулирующих документов, включая специальный ГОСТ. Ну а чтоб поставить что-то в серию, нужны огромные взаимоусилия.

Вопрос к Вам, Борис, с Вашего разрешения. Вы, как и автор топика, пишете о неких "проблемах взаимопонимания между разработчиками и пользователями". Поделитесь Вашим взглядом на этот вопрос. Я от автора так и не получил ответа, я не могу понять, что вы считаете проблемой (автор применяет термин "разрыв") между разработчикаом и пользователем?

Анатолий Курочкин пишет:
Очень спорный аргумент. Пользователям нужно не "как можно проще", а как можно функциональнее.

Именно это я имел в виду! Благодарю за уточнение! Проще в смысле - самое простое и подходящее решение стоящей задачи по функционалу!

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

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

Анатолий Курочкин пишет:
Разработчики не считают себя умнее других. Им не до этого, у них есть ТЗ, которое утверждает заказчик. Для постановки на производство существует целый набор обязательных процедур и регулирующих документов, включая специальный ГОСТ. Ну а чтоб поставить что-то в серию, нужны огромные взаимоусилия.

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

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

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

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

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

Анатолий Курочкин пишет:
Вопрос к Вам, Борис, с Вашего разрешения. Вы, как и автор топика, пишете о неких "проблемах взаимопонимания между разработчиками и пользователями". Поделитесь Вашим взглядом на этот вопрос. Я от автора так и не получил ответа, я не могу понять, что вы считаете проблемой (автор применяет термин "разрыв") между разработчикаом и пользователем?

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

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

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

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

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

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

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

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

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

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

Я могу лишь привести как намек(для меня в том числе это тоже намек) Андреса Штоль из Германии. У меня сложилось предположение, что у него нет проблем между разработчиками и пользователями потому, что "они в одной лодке"!

Я предполагаю, что Андреас и его команда сами являются частью команды прозводственных компаний, потому что вся информация стекается к нему в офис! Вероятно что нет дополнительной прослойки пользователей!

Если даже это не так, то эта идея мне очень нравится!:)

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

Анатолий Курочкин пишет:
Вопрос к Вам, Борис, с Вашего разрешения. Вы, как и автор топика, пишете о неких "проблемах взаимопонимания между разработчиками и пользователями". Поделитесь Вашим взглядом на этот вопрос. Я от автора так и не получил ответа, я не могу понять, что вы считаете проблемой (автор применяет термин "разрыв") между разработчикаом и пользователем?

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

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

...

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

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

Вы упомянули ранее про деливери-менеджмент. ...

Благодарю за ответ!  Хороший ответ!

Нет, я нигде не упоминал деливери-менеджиен. Я даже не знаю, что это такое. )))
Я так понял, что основной посыл автора связан с неорганизованностью его команды. 

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

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

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

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

Это разумно! Все таки приведу другие примеры.

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

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

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

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

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

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

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

Для этого нужно иметь наработки по гибкому взаимодействию и переброске людей с одного места на другое.

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

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