Я попытался сосредоточиться на ваших ключевых вопросах в вашей части TL;DR , но нашел время, чтобы пройтись по некоторым другим моментам.

Ключ TL;DR; Вопросы

Как я могу сообщить Еве, что все не так, как она думает?

Обратите внимание, что, основываясь на том, что вы сказали, также не было упомянуто никаких конкретных доказательств того, что все так, как вы думаете.

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

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

Поэтому помните об этом различии как об одной возможности.

С другой стороны, если мы предположим, что вы правы, похоже, вы мало что можете сделать. Сколько существует других разработчиков программного обеспечения, ответственных за воплощение приложений в жизнь? Похоже, что только вы и Адам вообще пишете код.

Вы также сказали, что

Адам и Ева очень близки

Я не знаю, что означает «очень близкие» в этом контексте (например, они часто тусуются, являются парой, семьей и т. д.), но в любом случае похоже, что уровень взаимопонимания/доверия между ними выше. чем у тебя. (Вы не говорите, как долго вы были там и т. д.) Я думаю, что это может еще больше усугубить восприятие любой критики, независимо от того, насколько она благонамеренна, особенно если вы отчитываетесь перед Адамом, а не перед Евой.

Какие у меня есть альтернативы, чтобы указать на это Адаму и/или Еве?

Из того, что вы сказали, не похоже, что есть много хороших альтернатив. Думаю, я подготовлю свое резюме и начну искать в другом месте. Если они обвиняют вас сейчас, они также будут обвинять вас, когда проект потерпит неудачу, даже если это было связано с их собственными методами управления (или их отсутствием); это не похоже на среду, в которой я хотел бы остаться.

Если вы скажете Адаму, что это его вина, он не скажет: «Да, это справедливо; позвольте мне сказать Еве, насколько я с этим согласен».

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

Если Ева по какой-то причине доверяет Адаму больше, чем вам (и похоже, что так оно и есть), то обращение к Еве будет просто упражнением в том, чтобы выстрелить себе в ногу.

Кроме того, хотя ваши намерения могут быть благими, маловероятно, что они хорошо воспримут ваш непрошенный совет руководства[1]. Просто найдите другое (и, надеюсь, лучшее) место работы и оставьте провал любых будущих проектов недвусмысленным следствием их собственных действий; их плохая практика управления и/или техническая компетентность Адама (или ее отсутствие) будут единственными вещами, в которых можно винить после того, как вас больше не будет.

Другие детали

[Я] сделал несколько предложений, например, иметь список требований для каждой задачи, поскольку в настоящее время мы не следуем этому процессу, и чтобы он проверял мою работу, когда я «сделаю».

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

Вы проводите ежедневные стендап-митинги? Если нет, вы должны. (Подробнее ниже.)

Сегодня у нас была еще одна функция, которую нужно было переделать, она была закончена до того, как я ушел в отпуск, но Адам / Эвен решил классифицировать данные на сервере, когда меня не было. Адам сделал это на сервере сегодня, но приложению нужно чтобы отразить это изменение. Следовательно, он не смог классифицировать данные о приложениях

Тогда это подходящий момент, чтобы недвусмысленно констатировать следующие факты:

• функция была реализована до вашего отъезда, исходя из требований того времени;
• требования были произвольно изменены Адамом;
• Адам внес эти изменения во время вашего отсутствия

Вы можете переформулировать его как угодно, но вы должны четко указать, что это за факты. Если выяснится, что вас обвиняют за вашей спиной, то сейчас самое время использовать факты в свою пользу, не требуя прямого обвинения. Моей стратегией здесь было бы просто представить факты как часть обычного разговора и позволить фактам говорить самим за себя.

Ева — Адаму: почему данные [так в оригинале] не классифицируются? Адам смотрит на меня и говорит: Я так и думал! Я: Нет, в последний раз мы касались этого экрана со стороны приложения перед тем, как я уехал в отпуск.

Я думаю, что в вашем ответе здесь не были учтены соответствующие факты, на которые я указал выше. Любой разумный человек должен сделать вывод, что обижаться на вас в данной ситуации неразумно . Тем не менее, я также встречал неразумных людей, так что...

Адам всегда микроуправляет (а иногда и Адамом, и Евой) моей работой.

Думали ли вы сказать, что, может быть, просто может быть, если бы они позволили вам выполнять ваши задачи без постоянных указаний, как выполнять вашу работу, тогда, возможно, вы могли бы быть более продуктивными / успешными и, таким образом, помочь им быть более успешными, чем они уже есть, особенно после нескольких неудачных проектов?

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

[они] всегда в курсе всего, что я делаю, ежечасно.

Это очень разрушительно, особенно для разработчика программного обеспечения . Учитывая, что разработка программного обеспечения связана с решением проблем в вашей голове , постоянные перерывы могут нарушить ваш мыслительный процесс.

Это все равно, что часто обливать водой того, кто пытается разжечь костер, а затем ожидать, что он добьется успеха в разведении костра. Это абсурд.

Вы все должны согласиться проводить одно ежедневное собрание, на котором все сообщают свои новости, обсуждают проблемы и решения, а затем возвращаются к работе без ненужных перерывов. Эта встреча обычно длится около 15-20 минут, и некоторые из тем, которые каждый должен рассмотреть, включают:

• Что вы делали накануне (например, вчера я делал A, B, Cи т. д.)
• Любые препятствия, с которыми вы столкнулись (например, я застрял на задаче D; я хотел бы обсудить возможные решения после того, как все остальные предоставили свои обновления)
• Что вы собираетесь делать сегодня (например, сегодня я собираюсь закончить Dи приступить к работе E)

Каждый участник предоставляет одну и ту же информацию во время каждой встречи, каждый день. В конце концов , это ежедневный стендап. :)

Я договорился с Адамом, что вернусь из отпуска, и мы начнем сборку двух тестовых устройств и интегрируем остальные функции.

Я никогда не был в стартап-среде, но что-то мне подсказывает, что в этой среде все быстро меняется. Поэтому тот факт, что они сделали это, пока вас не было, не должен быть проблемой. С другой стороны, это также не должно быть использовано против вас.

Источником этих проблем, по моему мнению, являются несколько технических и управленческих недостатков.

Я не думаю, что вы можете многое сделать, кроме как сменить менеджеров. Подумайте, обсуждалось ли что-либо из следующего:

• вещи, которые, по вашему мнению, вы определили как проблемы;
• потенциальные способы обхода/решения этих проблем;
• почему вы считаете, что предлагаемое решение может сработать;

и было ли это сделано до того, как проекты потерпели неудачу, или, по крайней мере, сразу после последней неудачи, если вообще. Если после нескольких неудач ничего не изменилось , не вижу причин думать, что что-то изменится.

Именно по этой причине методологии Agile включают групповую ретроспективу в конце каждого спринта (т. е. не проекта!): чтобы дать возможность подумать о том, что получилось, а что не очень хорошо в спринте, и взять на себя обязательство исправить это в конце каждого спринта. следующий.

Вы не ждете, пока проект потерпит неудачу, и уж точно не ждете, пока потерпят неудачу несколько из них. Если есть отказ на любом уровне учиться на прошлых ошибках, они просто будут повторять их и терпеть неудачи. Первый шаг к устранению проблем — признание их существования.

Кроме того, если ничего не улучшится, проекты будут продолжать терпеть неудачу, они закончатся банкротством компании, и вы станете безработным, если решите остаться там. Единственный способ, которым вы можете сменить своих менеджеров, — это найти другую работу.

Сноски

[1] Однажды у меня был менеджер M, которого назначили Lруководителем группы. К моему удивлению, Mво время «оценки производительности» мне сказали , что задачи, над которыми я работал, «не важны». Мой ответ Mбыл, в основном, что это Lбыл тимлид, что его обязанность как ведущего заключалась в том, чтобы определить/создать истории, над которыми он хотел, чтобы мы работали во время наших спринтов, и что, согласно L, задачи были «очень важными». ". Поступил ли Mон разумно и сказал: «Спасибо, что обратил на это мое внимание; я поговорю с Lвами, потому что, похоже, у нас разные представления о том, что важно»? Нет. Она просто больше расстроилась и ничего не исправила...