В теме 22 ответа, и 7 участников, последнее обновление сделано пользователем 
Стас С 13 г, 9 мес. назад.
-
Сообщения
-
А я соглашусь и не соглашусь =)
Живое общение тоже может быть не эффективным, если у разработчика плохо с коммуникацией.
Зато если все ок и человек адекватный, то иногда и спеки писать не нужно, что весьма радует.
Как-то один мой знакомый пошутил, что в идеальном мире над каждым разработчиком нужно поставить по аналитику (желательно девушку с большим бюстом), чтобы он рассказывал что делать, выслушивал и т.п. И вот тогда все будет в шоколаде.
На мой взгляд тут уже получается double-work. Как однажды я столкнулась на проекте с высказыванием "Эту спеку ты же для заказчика пишешь, а мне отдельно все расскажи-нарисуй-напиши". Если мы сначала будем спеки писать, стараясь в них все мелочи описывать, потом дополнительно каждое изменение описывать в спеке, проговаривать сначала разработчикам, потом тестировщикам, и т.д., мы вряд ли выйдем на хороший уровень по результатам проекта
Все-таки присоединюсь к последним двум высказываниям. Спеки и пишутся во многом, чтобы избежать реворка. Живое общение, конечно, огонь, но если тебя дергают 15 девелоперов, не читавших спеки, нервы скоро сдадут. В любой работе есть интересные и неинтересные моменты и на мой взгляд просто надо с ними мириться и тем не менее делать. Это касается и прочтения спек для разработчиков.Лично мне не сложно найти 5 минут на то, чтобы просмотреть вместе с девелопером спецификацию, вкратце рассказать о том, что нужно сделать и ответить на его вопросы (или указать на место в документе, где на них отвечено). Понятное дело, не стоит собирать митинг, если в спеке обновилось 1-2 предложения, достаточно их выделить так, как принято в команде, и дать знать, что документ обновился.
Порой эти 5 минут позволяют сэкономить много времени в будущем: с одной стороны, когда девелопер читает спеку, по ходу у него могут появиться вопросы, которые можно было покрыть при первом обсуждении (и задаются они часто не сразу все, а по 1-2 по мере прочтения, что каждый раз влечет отрыв от работы). С другой стороны, сразу лично убеждаешься, что человек понял, что от него требуется (есть и такие, кто спросить лишний раз постесняется/поленится, сделает на свое усмотрение и далеко не всегда правильно). Понятное дело, что такая позиция неправильна, но если можно минимизировать проблемы от нее на начальном этапе — почему бы не сделать это?
С третьей стороны, мне нравится получать фидбек от разработчиков. Бывает, что у них есть опыт в областях, с которыми я малознакома/незнакома, и они могут внести оптимизаторские предложения. Ну и потом разве это не приятнее, чем общение с тупо исполнителем?А вот я за редкостный баланс (:
Баланс между проговариванием задания и отсутствием общения вообще.
Баланс нужен для того, чтобы что-то сложное (формулы и куча другой сложнопроговариваемой инфы) оставалась в любом случае в спеке (ведь она нужна для реализации, неправда ли?). Нужен он и для того, чтобы закрыть "непонятную" часть спеки для данного разработчика или группы разработчиков. Эта "непонятная" часть может быть в спеке, потому что спека не идеальна (ведь бывает и такое, признайтесь себе, наконец), потому что конкретно этот разработчик не понял и т.д. Но ведь цель у нас донести правильную информацию, а спека — это всего лишь один из способов. И мы не зря дополняем текст диаграммами, картинками и т.д. Все эти средства мы используем для того, чтобы наиболее точно и правильно передать информацию.Упомянутый баланс можно достигнуть специальными небольшими хорошо организованными сессиями, на которых аналитик будет презентовать свою спецификацию разработчикам, тестировщикам и другим заинтересованным лицам. В результате такой сессии, улучшится понимание и, вероятно, исправятся многие ошибки в документах. Продложительность сессии определяется размером спеки, размером команды, загруженностью людей и другими факторами.
На мой взгляд, игнорирование спецификаций-это, на самом деле, неуважение к БА и элементарная лень, а не предпочтение живого общения. Общение с девелопером на уровне расскажи, покажи, а спеку я читать не буду- это нерациональное использование времени аналитика, которое он мог бы потратить с большей пользой.Аналитик должен отвечать на вопросы, неописанные в спеке либо описанные непонятно.
О! Вот это мнение! Спасибо, полностью согласна! Ответить на неясные вопросы — пожалуйста. Но пересказывать содержание и пальчиком тыкать, где что написано не то чтобы впадлу, но просто лишнее.На мой взгляд, игнорирование спецификаций-это, на самом деле, неуважение к БА и элементарная лень, а не предпочтение живого общения. Общение с девелопером на уровне расскажи, покажи, а спеку я читать не буду- это нерациональное использование времени аналитика, которое он мог бы потратить с большей пользой.
Ну, конечно, если цель аналитика разобраться в требованиях самому и написать как можно больше спек, а не донести их до окружающих наиболее наглядным и удобным способом, то тут не поспоришь.
Вы должны авторизироваться для ответа в этой теме.
