LINUX.ORG.RU
ФорумTalks

В чём причина нелюбви к энтерпрайзам?

 ,


0

1

Всем привет

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

Или для того, чтобы это понять, надо стать программированием на жизнь начать зарабатывать?

Спасибо


Ответ на: комментарий от shimshimshim

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

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

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

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

shimshimshim
()
Ответ на: комментарий от shimshimshim

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

Ну это зависит от заказчика. Его дело обсудить пожелания с пользователями.

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

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

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

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

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

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

shimshimshim
()
Ответ на: комментарий от shimshimshim

Должны разработчики думатьс сами, без ТЗ.

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

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

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

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

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

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

Именно что это разработчики, только неэнтерпрайзные. Не муравьи с узкой специализацией, которые могут копать, а могут и не копать, особенно не интересуясь резулттатом. Энтерпрайзным это трудно объяснить, да, проще воспитать новичка, показать ему как все работает.

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

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

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

shimshimshim
()

такой сочный тред без езернета

smilessss ★★★★★
()
Ответ на: комментарий от shimshimshim

Ты врешь 8)

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

Deleted
()
Ответ на: комментарий от Deleted

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

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

shimshimshim
()
Ответ на: комментарий от shimshimshim

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

Deleted
()
Ответ на: комментарий от Deleted

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

Кто видел корпоративное ПО, тот меня поймет. До сих пор считается нормальным писать так, что окошки не масштабируются в HighDPI и тексты выезжают за кнопки при увеличении шрифта в системе. Я уж не говорю про сто-то более сложное.

shimshimshim
()
Ответ на: комментарий от shimshimshim

корпоративное ПО,

До сих пор считается нормальным писать так, что окошки не масштабируются в HighDPI

тебя штырит, в корпоративном ПО чаще возникает вопрос почем на 1024 пиксела оно не влезает

Deleted
()
Ответ на: комментарий от shimshimshim

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

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

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

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

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

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

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

shimshimshim
()
Ответ на: комментарий от lenin386

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

torvn77 ★★★★★
()
Ответ на: комментарий от shimshimshim

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

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

В энтерпрайз сбегают обычно те, кто раньше работал в энтерпрайзе.

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

А ТЗ как такового при таком подходе нет.

Поздравляю, Шарик, у вас рабочим процессом руководят балбесы.

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

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

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

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

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

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

shimshimshim
()
Ответ на: комментарий от shimshimshim

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

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

Я кстати видал одного из не-энтерпрайза, где «программисты» пишут почти на всех языках. Вот это самый адъ, они ни одного из них не знают из-за широкой специализации, зато ЧСВ до Юпитера.

Эти люди пишут программы, и все.

У тебя они ещё общаются с пользователями и придумывают требования. Это уже не программисты.

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

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

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

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

Я кстати видал одного из не-энтерпрайза, где «программисты» пишут почти на всех языках. Вот это самый адъ, они ни одного из них не знают из-за широкой специализации, зато ЧСВ до Юпитера.

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

shimshimshim
()
Ответ на: комментарий от shimshimshim

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

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

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

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

vurdalak ★★★★★
()
Ответ на: комментарий от shimshimshim

ты энтерпрайзный программист

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

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

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

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

shimshimshim
()
Ответ на: комментарий от shimshimshim

исходя из твоих собственных критериев профессии программиста

Словарь мой собственный? Ок, дальше говорить не о чём.

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

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

shimshimshim
()
Ответ на: комментарий от shimshimshim

Да товарищь, словарь твой собственый. Ты его изобрел.

Ну всё, распечатаю твои слова и пойду требовать отчислений от издателей словаря.

vurdalak ★★★★★
()
Ответ на: комментарий от shimshimshim

Деньгами не получится — вдруг ты их пропьёшь, а пукан выстрелит по Вашингтону и начнёт третью мировую?

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

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

shimshimshim
()
Ответ на: комментарий от shimshimshim

ИМХО спор можно решить тем, что утверждение «тот, кто пишет программы» надо расширить до «тот, кто проектирует и пишет программы».
(опрос потребителей есть органичная часть проектирования)

torvn77 ★★★★★
()
Ответ на: комментарий от torvn77

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

shimshimshim
()
Ответ на: комментарий от shimshimshim

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

Ты даже не представляешь, насколько ты прав. Когда я вижу требования к софту, я уже представляю, как будут нас проклинать пользователи, которые попытаются это понять :)

Правда, я не знаю, как это связано с разработчиками. Я прекрасно понимаю что это неудобно для пользователя, но функционал настолько сложен что лучше никак не сделать. Кнопку «сделать збс» ещё не придумали.

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

Отлично представляю, потому что видел это своими глазами.

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

shimshimshim
()
Ответ на: комментарий от shimshimshim

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

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

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

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

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

shimshimshim
()
Ответ на: комментарий от vurdalak

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

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от shimshimshim

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

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

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

vurdalak ★★★★★
()
Ответ на: комментарий от torvn77

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

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

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

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

shimshimshim
()
Ответ на: комментарий от vurdalak

Сначала БА деформирует запросы клиента словами «таких технологии нет», «с этим мы не работаем» и прайсом на услуги.
когда клиент составит ДЕФРМИРОВАННЫЙ этим БА список своих требований и пожелании БА начнёт это переводить в ТЗ без учёта реальных процессов у пользователя и знания тонкостей решения задач программистом.
Он об этом просто не может знать,так как это даётся только не посредственным опытом работы
Потом сеньор примет это являющиеся недоразумением ТЗ за абсолютное желание заказчика(ну на то это и ТЗ) и программисты не имея представления об реальных нуждах клиентов начнут его реализовывать, при этом деформируя его под возможности конкретных инструментов.

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

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

А БА как таковой не нужен.

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 5)
Ответ на: комментарий от shimshimshim

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

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

vurdalak ★★★★★
()
Ответ на: комментарий от torvn77

Сначала БА деформирует запросы клиента словами «таких технологии нет», «с этим мы не работаем» и прайсом на услуги.

Конкретно там где я видел — нет.

когда клиент составит ДЕФРМИРОВАННЫЙ этим БА список своих требований и пожелании БА начнёи это переводить в ТЗ без учёта реальных процессов у пользователя и знания тонкостей решения задачей программистом.

Тоже нет. БА обсуждает ТЗ с разработчиками на стадии формирования.

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

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

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

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

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

vurdalak ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.