Единую и доступную для большинства методологию,так будет точнее, да.

>>72145

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

А щито поделать, если заказчик довольно часто сам не понимает чего хочет и/или хочет взаимопротиворечивых вещей?

САПРы какие-нибудь? Образовния не хватает чтобы что-нибудь понять?

>единую методологию моделирования информационных систем и бизнес-процессов

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

>>72148

>если заказчик довольно часто сам не понимает чего хочет и/или хочет взаимопротиворечивых вещей?

Заказчик - это вообще отдельный тред. Здесь речь скорее о взаимодействии консультантов, аналитиков и разработки. Методологий более 9000, а языка, понятного и тем и другим нет.
>>72149

>Образовния не хватает чтобы что-нибудь понять?

И это тоже в последнее время не редкость, дефицит кадров во все поля.

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

Манагеры же на стороне клиента. Но их кривые БП, которые один из десяти может писать - тоже отдельный разговор.

>>72150

> взаимодействии консультантов, аналитиков и разработки.

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

>>72151

>консультантов и аналитиков из разработки

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

>>72152

> принципиально иным образованием и, зачастую, мышлением?

Скорее учить и тому и другому одного человека.

>>72153

>учить и тому и другому одного человека.

6 лет длится обучение по одному направлению. Два направления, пусть частично суммируются, 10 лет. Ещё три года на производстве. В итоге спеца можно получить только тридцатилетнего. А кто будет за это платить?

>>72145
Обобщённая модель будет малополезна ввиду того, что она не учитывает никакой специфики, которую придётся точно так же описывать и согласовывать. Узкие методологии и так существуют в рамках сработавшихся комманд, но неприменимы для чего-то другого. Обесни лучше почему никто не умеет писать грамотного тз. Не рассматривают до конца даже общие случаи, при этом лезут чуть ли не со своей реализацией в никому не нужных мелочах. 90% текста совершенно бесполезно а оставшееся представляет собой требования вида "сделать заебись"

>>72154

> 6 лет длится обучение по одному направлению. Два направления, пусть частично суммируются, 10 лет.

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

>>72155

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

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

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

Потому что ты имел дело с плохими аналитиками или некудышными разработчиками. Либо и то и другое вместе взятое.
>>72156

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

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

>>72158

> Идёт описание программного продукта, для которого всё равно с чем мы работаем - с электрокомпаниями или со свинофермами.

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

> Потому что ты имел дело с плохими аналитиками или некудышными разработчиками. Либо и то и другое вместе взятое.

Манагеры ходят исключительно в белом?

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

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

>>72145
Опять будут ныть что новерь превратился в программач. При этом сами ничего не обсуждают, а только читают и ждут, когда же начнутся псевдонаучные обсуждения, а они не начнутся, пока вы сами их не начнёте! Хотя меня это тоже не радует, работы мне и на работе хватает, лучше бы об экспериментах по обнаружении нарушений инвариантностей поговорили или поспорили о роли наблюдателя в квантомеханических процессах как предпосылке к солиптическому восприятию мира.

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

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

> И там и там спецефичных вещей более чем дофига, причем и тем и другим нужен софт для работы со специфичными для них вещами.

Хорошо, что ты понимаешь под специфичными вещами, которые нельзя описать унифицированным языком?

> Манагеры ходят исключительно в белом?

Манагеры вообще к ИТ имеют весьма опосредованное отношение и их недочёты в описании БП должны выравнивать консультанты же.

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

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

>Кроме того те, кто пишут тз, как правило ничего не решают.

Как минимум, они решают как именно реализовывать проект разработчикам.

>>72163

> что ты понимаешь под специфичными вещами, которые нельзя описать унифицированным языком?

Зависит от языка.

> Манагеры вообще к ИТ имеют весьма опосредованное отношение и их недочёты в описании БП должны выравнивать консультанты же.

Что может сделать консультант если ТЗ представляет собой БП?

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

Довольно много людей несут десу, в качестве аргументации используя два в/о. Вот тебе пример: http://svetlana.peunova.ru/

> Как минимум, они решают как именно реализовывать проект разработчикам.

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

>>72164

>Зависит от языка.

UML, чтобы далеко не ходить?

>Что может сделать консультант если ТЗ представляет собой БП?

Согласовать с заказчиком, очевидно же. И как ТЗ может быть БП, если писать ТЗ по стандартам?

>Довольно много людей несут десу, в качестве аргументации используя два в/о.

Это ничего не доказывает. Гораздо большее количество несёт бред вообще не аргументируя.

>Вот тебе пример: http://svetlana.peunova.ru/

Не хотеть в политоту.

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

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

>>72163

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

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

>образование имеет прямую и довольно сильную корреляцию с уровнем интеллекта

Категорически не согласен исходя из личного опыта.

>Манагеры вообще к ИТ имеют весьма опосредованное отношение и их недочёты в описании БП должны выравнивать консультанты же.

Тем не менее они почти всегда используются в качестве сломанного телефона.

>Как минимум, они решают как именно реализовывать проект разработчикам.

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

>>72166

> UML, чтобы далеко не ходить?

Не позволяет описать действия в не совсем стандартных ситуациях.

> Согласовать с заказчиком, очевидно же.

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

> И как ТЗ может быть БП, если писать ТЗ по стандартам?

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

> Не хотеть в политоту.

Вот тебе еще: http://ithappens.ru/bytag/education

>>72161

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

ну так создай тред, поговорим
>>72162
это если тема обсуждения предусматривает влияние отношения кого-нибудь к этой теме, с чисто научными вещами такого не произойдет, вряд ли тут найдутся те кого выводит из себя какое-то научное направление или результаты экспериментов

>>72169

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

Тем не менее это не помешало кому-то получить фекалий на довольно простой вопрос несколько дней назад.

>>72167

>Бестолковых сразу выгонять, они не столько не приносят пользы, сколько времени остальных.

Но где ты толковых хочешь искать, если рынок труда дефицитен?

>Тем не менее они почти всегда используются в качестве сломанного телефона.

Как то так, но, опять таки, зависит от качества консультанта.

>Они вообще не должны знать ничего о реализации, только задачи и результаты.

А вот с этим уже я не согласен. Тот кто пишет ТЗ задним умом всё равно должен представлять как это будет реализовано, то есть, ТЗ должно быть выполнимо текущими средствами и в заданные строки. Иначе такое можно нагородить.
>>72168

>Не позволяет описать действия в не совсем стандартных ситуациях.

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

>И как ТЗ может быть БП, если писать ТЗ по стандартам?

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

>>72161
какая пушистая момиджи.

>>72171

> эксперная система

Разве заказчику не может понадобится что-то подобное?

> Алсо, а с каких пор ТЗ пишет заказчик? Консультант строит бизнес-процессы, руководит внедрением, аналитик пишет по ним ТЗ, оптимизирует и т.д., программисты реализуют, не?

Тебе часто попадались адекватные ТЗ?

>>72174

>Разве заказчику не может понадобится что-то подобное?

В 95% случаях - нет, чаще используют BI, но он формализован.

>Тебе часто попадались адекватные ТЗ?

Зависит от того что ты понимаешь под адекватными ТЗ.