Если ты ... (не очень подробные заметки на полях)

Если ты…(Внедряешься внутрь?)

Если ты – внутренний внедренец, то при составлении документов ты должен быть осторожен, описывая потребности стейкхолдеров в функциональности системы. Участие в «политических играх» не входит в твои «интересы». Эти описания ты должен делать для себя. Т.е. это будут не документы, а «заметки для внутреннего пользования». Но эти заметки все же должны существовать, чтобы ты сам имел возможность к ним обратиться в случае «повторного обращения» заказчика или если придется объяснять определенные нюансы разработки твоей команде.

Вывод: учти, что тебя будут ежедневно встречать в коридоре те самые пользователи, для которых ты внедряешь эту самую систему и абстрактная «обратная реакция» превратиться для тебя в совершенно конкретные высказывания по поводу «а на фига было вообще все это затевать?». Готовь крепкую нервную систему к очередному испытанию (слабонервных надо было удалить еще в самом начале J). Главное- будь четко уверен в необходимости того, что ты делаешь.

Если ты … (Ты - эксперт/консультант? Ух ты!!!)

Если ты «консультант по системе», то радостно наплюй на все возможные подводные камни проекта и радостно разъясняй людям «преимущество определенного покроя костюма» и невозможность «пришить вторую пуговицу». Ты специалист в этой конкретной системе и лучше тебя ее знают вообще-то не так много людей, а уж про знания системы теми людьми, которые гордо именуют себя "заказчиками", ты просто деликатно молчишь. Главная опасность для тебя - фраза "это противоречит логике системы". И ты можешь даже вслух ее не произносить (сдерживаться), но если она звучит у тебя в голове - ты в опасности. Ты сможешь скатиться в общение на профильных сайтах, думать терминами и логикой системы\продукта и в итоге твой продукт/система станут для тебя "системой ценностей и взглядом на жизнь".
Вывод: читай больше про другие системы\продукты\варианты. И даже если работа с данным продуктом стала для тебя стилем жизни, а ее (жизни) смыслом стала борьба с другими продуктами\системами - все равно изучай все новое. Ты хотя бы будешь знать врага в лицо.

Если ты ... (Ты - руководитель проекта. И теперь многое будет по-другому)

Если ты «руководитель проекта» – наплюй на функциональность системы и на систему в принципе, и думай о подтверждении договоренностей, о ясности целей и оценке результата, о подборе и мотивации команды. Ты настоящий "руководитель проекта" если у тебя есть набор сертификатов, если ты разбиваешь приготовление завтрака на этапы, если тебе сначала становится все равно из чего ты готовишь завтрак, потом - в какое время суток ты его готовишь, потом ты перестаешь особо думать в какой обстановке "условный завтрак" готовится (на кухне или в лесу), а на пике карьеры ты не будешь даже слушать предложения приготовить завтрак из продуктов общей стоимостью меньше ... у.е.
Вывод: ты сумеешь реализовать проект в любой области, ты будешь иметь портфель проектов, список публикаций, перечень сертификатов. Но старайся периодически выполнять и другие роли в проектах. Главная опасность для тебя - превратиться в высоколобого эксперта, преподающего в престижном заведении.

Если ты профессионал – думай обо всем, кроме того, как тебя называют в проекте.

Вывод: будь профессионалом. И не позволяй себе присутствия на совещаниях о проектах по поводу «семи перпендикулярных линий разного цвета». Если тебя пригласили на такое совещание, значит что-то ты делаешь не так. J

Если ты…. (Ты – аналитик в команде разработчиков? Поздравляю J)

Если ты «аналитик» – наплюй на ресурсы, бюджеты, сроки и думай о потребностях, значимости, применимости, вариантах использования. Стать действительно авторитетным аналитиком в сложившейся команде очень непросто. Ведь ты должен общаться с разработчиками «на их языке», т.е. они должны понимать тебя, а в большей степени ты должен понимать их. При этом ты должен абсолютно четко понимать – чего хочет конкретный руководитель конкретного подразделения, конкретный пользователь в каждом конкретном случае. И понимая все это, доказывать (будучи членом команды) разработчикам необходимость «реализовать именно в таком сценарии».
А иметь авторитет в команде разработчиков тебе, как аналитику, просто необходимо. Иначе ты будешь вынужден постоянно обращаться к «административному ресурсу» в виде руководителя проекта для решения вопросов.
Вывод: Четко зная, что тебе необходимо в качестве функционала, говори с программерами – они вообще-то хорошие люди. Поймут и простят, если что.  Говори с ними, показывая им на схемах – что пользователи хотели бы. Но перед тем, как начинать разговор с ними – максимально подробно для самого себя уясни что именно требуется от системы. Они эксперты в свойствах системы и коде, ты – эксперт в требованиях. Говори как эксперт с экспертом.