Если ваша фирма занимается выпуском продукта, то просто необходимо иметь небольшой документ, который объясняет, а зачем все это вообще нужно и какие проблемы продукт должен решать, и какие не должен.
Естественно, этот документ должен быть «живым». То еcть на него не нужно молиться по утрам и он не должен быть высечен в камне подобно заповедям. Скорее, такой документ должен переглядываться, раз в пол года или год.
Зачем собственно он нужен? Как это не странно звучит, но у каждого сотрудника есть свое мнение по тому поводу, зачем нужен продукт. И вы не поверите насколько эти мнения будут расходится, начиная от «коробочка из под продукта очень хорошо под монитор ложиться» и заканчивая «настойки на этом программного продукте помогают против гриппа и простуды». Как я подозреваю, любой руководитель хотел бы, чтобы люди в компании понимали, куда вообще идет фирма и зачем продукт нужен. Ну и для этого и нужно иметь «централизованное» понимания, чтобы мнения у людей не расползались во все стороны с дикой скоростью.
Обычно, когда начинаются вопросы по улучшениям каких-то свойств программы, обнаруживается, что люди «тянут одеяло» на собрании абсолютно в разные стороны, причем, начиная аргументировать свои решения именно своим внутренним пониманием. И чаще всего выходит ситуация лебедь-рак-щука. Причем, начальству тяжело что-то аргументировать, кроме как сказать – Вася, а тебя попросим в ход спора не вмешиваться.
Так что, такой документ устанавливает своеобразные правила спора, чтобы собрание из спора фактов не становился спором мнений. Документ должен содержать список основных проблем, которые продукт призван решать и основные направления в которых он должен развиваться.
И после этого, если вы пишите программу по хранению генеалогического дерева, не у кого не должно приходить в голову идей о том, что «давайте туда встроим мощную модуль управления спутниками».
это что-то типа пресс-релиза?
2Anonymous: Не совсем понял вопрос. Вы о посте или о документе?
Если о документе — то скорее это не пресс релиз, а user-cas’ы. То-есть список проблем, которые мы пытаемся решить.
Как пример, в документе может быть написано, мы выпускаем программу для пользователей, которые плохо слышат. Программа должна автоматически регулировать громкость в таких-то случаях. Мы собираемся расширять ее в область совсем не слышаших, мы не собираемся расширять ее в область для людей с плохим зрением и т.п.
В таком случае, все будут осознавать, что программа решает сейчас и что она собирается решать завтра.
Хотя все это кажется тривиальным, но чем больше фирма тем меньше понимания у каждого программиста и тестировщика, что вообще происходит и куда движется.
Дельно.
Очень часто с подобными проблемами сталкивался.
2pnv82: Аналогично. Сначала долго бился головой об стену и только потом понял, что просто каждый понимает по своему продукт.
А как делали этот документ?
Ведь его согласование, путь оно и не каждодневное, тоже штука не простая. Или кто-то взял это на себя?
2pnv82: Вообще документ должен делаться высшим менеджментом/основателями/другими финансово вовлеченными лицами. Документ этот не делается демократическим путем в виде согласования с многими людьми в компаниями. Он просто должен идти сверху вниз.
[…] Нафига козлу баян […]