"Разработчики не читают мои документы" (страница 2)




Главная   Форумы   Общие вопросы и обсуждения   "Разработчики не читают мои документы"

В теме 22 ответа, и 7 участников, последнее обновление сделано пользователем Аватар (Стас С) Стас С 7 г, 4 мес. назад.

Показано 8 ответов - от 16 до 23 (всего 23)
  • Автор
    Сообщения
  • 14.07.2010 в 11:02 # 4303
    Аватар (Yuliya Shamrei)
    Юлия Шамрей
    Участник
    А я соглашусь и не соглашусь =)
    Живое общение тоже может быть не эффективным, если у разработчика плохо с коммуникацией.
    Зато если все ок и человек адекватный, то иногда и спеки писать не нужно, что весьма радует.
    Как-то один мой знакомый пошутил, что в идеальном мире над каждым разработчиком нужно поставить по аналитику (желательно девушку с большим бюстом), чтобы он рассказывал что делать, выслушивал и т.п. И вот тогда все будет в шоколаде. :D
    Поделиться:

    Цитировать

    14.07.2010 в 11:06 # 4304
    Аватар (Anna)
    Anna
    Подписчик
    На мой взгляд тут уже получается double-work. Как однажды я столкнулась на проекте с высказыванием "Эту спеку ты же для заказчика пишешь, а мне отдельно все расскажи-нарисуй-напиши". Если мы сначала будем спеки писать, стараясь в них все мелочи описывать, потом дополнительно каждое изменение описывать в спеке, проговаривать сначала разработчикам, потом тестировщикам, и т.д., мы вряд ли выйдем на хороший уровень по результатам проекта :)
    Поделиться:

    Цитировать

    14.07.2010 в 14:05 # 4305
    Все-таки присоединюсь к последним двум высказываниям. Спеки и пишутся во многом, чтобы избежать реворка. Живое общение, конечно, огонь, но если тебя дергают 15 девелоперов, не читавших спеки, нервы скоро сдадут. В любой работе есть интересные и неинтересные моменты и на мой взгляд просто надо с ними мириться и тем не менее делать. Это касается и прочтения спек для разработчиков.
    Поделиться:

    Цитировать

    14.07.2010 в 14:26 # 4306
    Аватар (Belle Morte)
    Belle Morte
    Админ
    Лично мне не сложно найти 5 минут на то, чтобы просмотреть вместе с девелопером спецификацию, вкратце рассказать о том, что нужно сделать и ответить на его вопросы (или указать на место в документе, где на них отвечено). Понятное дело, не стоит собирать митинг, если в спеке обновилось 1-2 предложения, достаточно их выделить так, как принято в команде, и дать знать, что документ обновился.
    Порой эти 5 минут позволяют сэкономить много времени в будущем: с одной стороны, когда девелопер читает спеку, по ходу у него могут появиться вопросы, которые можно было покрыть при первом обсуждении (и задаются они часто не сразу все, а по 1-2 по мере прочтения, что каждый раз влечет отрыв от работы). С другой стороны, сразу лично убеждаешься, что человек понял, что от него требуется (есть и такие, кто спросить лишний раз постесняется/поленится, сделает на свое усмотрение и далеко не всегда правильно). Понятное дело, что такая позиция неправильна, но если можно минимизировать проблемы от нее на начальном этапе — почему бы не сделать это?
    С третьей стороны, мне нравится получать фидбек от разработчиков. Бывает, что у них есть опыт в областях, с которыми я малознакома/незнакома, и они могут внести оптимизаторские предложения. Ну и потом разве это не приятнее, чем общение с тупо исполнителем?
    Поделиться:

    Цитировать

    14.07.2010 в 14:41 # 4307
    А вот я за редкостный баланс (:
    Баланс между проговариванием задания и отсутствием общения вообще.
    Баланс нужен для того, чтобы что-то сложное (формулы и куча другой сложнопроговариваемой инфы) оставалась в любом случае в спеке (ведь она нужна для реализации, неправда ли?). Нужен он и для того, чтобы закрыть "непонятную" часть спеки для данного разработчика или группы разработчиков. Эта "непонятная" часть может быть в спеке, потому что спека не идеальна (ведь бывает и такое, признайтесь себе, наконец), потому что конкретно этот разработчик не понял и т.д. Но ведь цель у нас донести правильную информацию, а спека — это всего лишь один из способов. И мы не зря дополняем текст диаграммами, картинками и т.д. Все эти средства мы используем для того, чтобы наиболее точно и правильно передать информацию.

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

    Поделиться:

    Цитировать

    14.07.2010 в 15:24 # 4308
    Аватар (Сара Гиршфельд)
    Сара Гиршфельд
    Подписчик
    На мой взгляд, игнорирование спецификаций-это, на самом деле, неуважение к БА и элементарная лень, а не предпочтение живого общения. Общение с девелопером на уровне расскажи, покажи, а спеку я читать не буду- это нерациональное использование времени аналитика, которое он мог бы потратить с большей пользой.

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

    Поделиться:

    Цитировать

    14.07.2010 в 15:31 # 4309
    Аватар (Anna)
    Anna
    Подписчик
    О! Вот это мнение! Спасибо, полностью согласна! Ответить на неясные вопросы — пожалуйста. Но пересказывать содержание и пальчиком тыкать, где что написано не то чтобы впадлу, но просто лишнее.
    Поделиться:

    Цитировать

    14.07.2010 в 18:40 # 4310
    Аватар (Стас С)
    Стас С
    Подписчик

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

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

    Поделиться:

    Цитировать

Показано 8 ответов - от 16 до 23 (всего 23)

Вы должны авторизироваться для ответа в этой теме.