16

Проектирование / Re: Постановка задачи программисту

« : 08 Октября 2010, 05:18:45 »

Не скриншот, а нарисовать от руки....

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

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

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

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

Поэтому делайте скидку на масштаб. Что позволено быку недопустимо для Юпитера:))

17

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 08 Октября 2010, 03:41:16 »

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

18

Системный Анализ и Требования / Re: Противоречивость требований

« : 08 Октября 2010, 03:25:01 »

Я говорю о ситуации когда главное ЛПР - тех директор. А конфликт у бухгалтеров.
Моя задача как аналитика в первую очередь добиться максимальной удовлетворенности пользователя в рамках оговоренного бюджета.

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

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