Как коллега аналитик, могу дать советы которыми я пользуюсь при общении с разработчиками.
1) Прежде чем звонить человеку, сформулируйте список вопросов письменно и отправите ему в чате или в письме, если по ответам возникнут вопросы, так же письменно попросите прокомментировать непонятные вещи и только если останется недопонимание, его уже можно будет предметно обсудить, 90 % что вам даже созвон не понадобится.
2) Старайтесь закладывать в любую задачу не оптимистичные сроки, а пессимистичные, помните, другие люди как и вы работают и у них может быть огромный список задач, сразу они вам не ответят и задачу не сделают.
3) Перед тем как спрашивать, у архитекторов или разработчиков, как работает та или иная функция, лучше пойти прочитать документацию проекта, чтобы иметь представление хотя бы частичное, о задаче, может и спрашивать тогда нечего не придется. ( Если документации нет вообще, тут конечно беда)
4) Если вам дали задачу и вы ее ведете, а от вас требует конкретные даты готовности, но вы не можете сами оценить примерный срок когда будет готово, попросите более опытных коллег вам помочь, так же письмом с назначением встречи, через календарь или другое средство которое принято вас в команде.
И в целом общий совет, старайтесь к любой встречи где будет техническое обсуждение, уже иметь для разработчиков или тех людей которым вы будите задавать вопросы, документ который можно будет предметно обсуждать, это может быть , спека(спецификация), ФТ( функциональные требования) ФД ( функциональный дизайн), диаграммы, ППР(протокол проектного решения)или простенький документ с буллитами вида : описание что сдаем
что нового в задаче
информация которую предоставил заказчик
о чем договорились с заказчиком
вопросы которые необходимо уточнить.
И тогда работать будет проще в любой команде. старайтесь не наседать на коллег звонками по 2 минуты( на самом деле они не идут 2 минуты), это тратить и ваше и их время.
У меня например был опыт, банкротство компании RedSys в которой я работал. Когда стало понятно что компания все, я просто спокойной искал новую работу находясь еще в компании, а потом уже в суде отбивал деньги вместе с коллегами которая компания нам не выплатила, часть выплат который нам присвоил суд я все еще не получил. Так что тут надо еще брать в риск, что часть денег вам просто могут не вернуть если все пойдет по негативному сценарию.
Как коллега аналитик, могу дать советы которыми я пользуюсь при общении с разработчиками.
1) Прежде чем звонить человеку, сформулируйте список вопросов письменно и отправите ему в чате или в письме, если по ответам возникнут вопросы, так же письменно попросите прокомментировать непонятные вещи и только если останется недопонимание, его уже можно будет предметно обсудить, 90 % что вам даже созвон не понадобится.
2) Старайтесь закладывать в любую задачу не оптимистичные сроки, а пессимистичные, помните, другие люди как и вы работают и у них может быть огромный список задач, сразу они вам не ответят и задачу не сделают.
3) Перед тем как спрашивать, у архитекторов или разработчиков, как работает та или иная функция, лучше пойти прочитать документацию проекта, чтобы иметь представление хотя бы частичное, о задаче, может и спрашивать тогда нечего не придется. ( Если документации нет вообще, тут конечно беда)
4) Если вам дали задачу и вы ее ведете, а от вас требует конкретные даты готовности, но вы не можете сами оценить примерный срок когда будет готово, попросите более опытных коллег вам помочь, так же письмом с назначением встречи, через календарь или другое средство которое принято вас в команде.
И в целом общий совет, старайтесь к любой встречи где будет техническое обсуждение, уже иметь для разработчиков или тех людей которым вы будите задавать вопросы, документ который можно будет предметно обсуждать, это может быть , спека(спецификация), ФТ( функциональные требования) ФД ( функциональный дизайн), диаграммы, ППР(протокол проектного решения)или простенький документ с буллитами вида :
описание
что сдаем
что нового в задаче
информация которую предоставил заказчик
о чем договорились с заказчиком
вопросы которые необходимо уточнить.
И тогда работать будет проще в любой команде. старайтесь не наседать на коллег звонками по 2 минуты( на самом деле они не идут 2 минуты), это тратить и ваше и их время.
�
У меня например был опыт, банкротство компании RedSys в которой я работал. Когда стало понятно что компания все, я просто спокойной искал новую работу находясь еще в компании, а потом уже в суде отбивал деньги вместе с коллегами которая компания нам не выплатила, часть выплат который нам присвоил суд я все еще не получил. Так что тут надо еще брать в риск, что часть денег вам просто могут не вернуть если все пойдет по негативному сценарию.
Если у вас нет нормального ВУС то такое крайне маловероятно.