Как найти общий язык с сотрудниками военных предприятий, чтобы они дали описание своих процессов для составления ТЗ?
Добрый день
компания планирует разрабатывать программное обеспечение для военных предприятий. Я аналитик, буду собирать требования у сотрудников госпредприятий, готовить документы, передавать задания программистам и т.д..
Я знаю как собирать требования, умею готовить ТЗ т.д. Проблема в том, что описывать свою работу, свои процессы люди "не хотят".
Наслышан о ситуации, о типах людей с кем надо будет работать. знакомые, сказали что на госпредприятии часто, очень трудно получить описание того, как они работают и что хотят. Сотрудники (военные), могут и послать матом либо послать для чтения военных документов. Но эти документы очень старые, по ним невозможно делать ПО для текущих их нужд.
Поэтому родился вопрос, хочется все таки сделать качественно свою работу. Какую коммуникационную стратегию использовать? Какой подход использовать для таких сложных клиентов?
0. Без бумажки ты никто - получи корочку фсб
1. Без бумажки ты ничто - любой опрос "спеца" заканчивается его подписью на бумаге с его тезисами
2. Без бумажки ты никак - требуй, чтоб посыл в библиотеку содержал номер документа, номер стелажа, полку и имена всех родственников библиотекарши. Под роспись
Ну и наконец, если ты уволишься с данной работы ASAP ты окажешь большую услугу себе и своим близким
Вы аналитик, и вы даже не начали работу, а уже сразу на тостер?
Может быть вам стоит найти другого, более опытного аналитика и поручить работу ему?
Пообщайтесь с предыдущим аналитиком.
Попробуйте найти и узнать какие программы уже вводились, кем, и пообщаться с ними. Если найдете вариант успешного внедрения - вот с теми людьми пообщайтесь более плотно.
На самом деле пустой вопрос.
Никакой специфики в работе с военными в этом плане нет.
Ваша задача составить грамотное ТЗ и подписать его у заказчика. Уж как вы будете получать информацию, договариваться и убеждать это исключительно ваши проблемы, и общих советов тут быть не может. Все крайне индивидуально в каждом случае.
Если ТЗ составлено грамотно и подписано заказчиком - проблем не будет.
Если ТЗ составлено неграмотно (неважно по какой причине) - не берем проект в работу и избегаем проблем.
Вы уверены, что люди которые поставлены отвечать вам на вопросы это компетентные люди?!
Как делился опытом аналитик, люди которые были даны ему на ответы - были просто некомпетентны. Они не отвечали не по причине секретности, а по причине того, что они непроходимо необразованны и тупы и даже собственные процессы не знают. Поэтому, не дают их огласке.
С трудом удалось это донести до высшего состава, и с трудом найдя людей которые идут на контакт, получалось хоть в какой то мере получать информацию.
Рекомендую советовать руководству проекта закладывать в договор буфер на риск того, что информацией ни кто делится не будет и увеличивать сроки на аналитику в связи с тем, что необходимо додумывать&догугливать&википидить самому.
Вам нужно почитать профильную литературу. Советую Вигерса, Разработка требований к ПО. Есть в нете в виде PDF. Расставит все точки над i, по поводу работы с требованиями.
Простой
Простой
Простой
Простой
Простой
Простой
