Кто управляет деятельностью разработчика?

У меня такой вопрос. Я Джун и в организации ко мне приставили менеджера, который мной управляет. До этого в организациях мной всегда управлял лид (технический специалист), но не менеджер и я не знаю, как оно должно быть в нормальной фирме, возможно, ориентируясь на зарубежные фирмы. Она мне диктует, сколько я должна тратить время на изучение технического задания, какие вопросы и в какой форме я должна задавать. Например, она сказала, что рассказ о проекте, где я буду работать, идёт 15 минут. Хотя за 15 минут там точно не разберёшься, потому что техническое задание размытое. Потом, чтоб я не задавала вопросы, она сказала в письменной форме их подготовить, хотя по Скайпу это все намного быстрее. Потом она мне указывает, что, когда мне дают задачу, то вопросы по ней я должна задать сразу, хотя у меня вопросы могут возникнуть по мере выполнения задачи. Затем на аттестации она дала мне характеристику. Я не понимаю, почему этим не занимается технический специалист, что может знать экономист в технической части? Вообще это правомерно, что менеджер пишет мне характеристику и даёт мне рекомендации? Скажите, пожалуйста, как оно должно быть?


Ответы (2 шт):

Автор решения: Barmaley

Ну в общем то да, обычно джуном (да и вообще разработчиком) управляет тим лид.

То о чем вы пишете крайне напоминает процесс "удушения" нерадивого сотрудника (руководство видимо так решило), по крайней мере, задействованы стандартные инструменты такого "удушения", типа:

Именно поэтому вам приставлен менеджер, а не слабовольный тим лид.

Следующим, очевидно пойдет вручение вам письменного задания с требованием расписаться в его получении (если откажетесь - то отказ будет заактирован в присутствии 2-х свидетелей). Далее 2-3 таких задания/отказа, аттестация, потом уже увольнение по статье - опыт говорит, что с начала процесса это занимает от месяца до двух.

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

P.S. Ничего личного. Просто наблюдения на основе опыта.

→ Ссылка
Автор решения: Alex Krass

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

У нас такая ситуация может тоже быть, когда PM пытается руководить командой, но это в случае дедлайнов, когда не хватает людей и они все заняты на других проектах. Проекты и команды тоже часто меняются. В принципе ничего страшного в этом нет. Единственное у нас нет джунов и младших миддлов, а общение зрелых разработчиков с PM происходит не совсем в плоскости "мне сказали - я исполнил", тут больше совместная работа и решение общих проблем команды. А в случае конфликтов могут и поругаться, но это обычно редкость. За людьми, которые только начинают свой путь, должен присматривать наставник и быть прослойкой между вами и PM. Если этого нет, то в принципе это еще не показатель.

Я бы посоветовал вам обратить внимание сейчас на такие моменты:

  1. Если PM дал задание, нужно постараться его исполнить или озвучить проблемы по его исполнению. Пускай даже вам дали установки со сроками, но вы просто должны обосновать их невыполнение, страшного в этом ничего нет.
  2. Если вы делаете задачу и возникли вопросы, обращаетесь за помощью и спрашивайте кто вам может помочь (вопрос технический к разрабам или по бизнес-процессам к аналитикам). Это тоже часть работы в команде, что вы не сидите зажавшись в углу и ничего не делаете в случае неуспеха. Такое тоже случается и не только с джунами.
  3. Реакция на такие вещи должна быть более-менее адекватной (там могут поругаться, но помощь должна быть оказана). Посмотрите, насколько адекватными будут действия, если у вас возникнут проблемы.
  4. У вас должны быть коллеги, с которыми вы общаетесь по рабочим моментам, желательно с code review после выполнения задач.
  5. Задачи должны быть вам под силу, может быть и со скрипом, но все-таки выполнимы.
  6. Старайтесь не обращать внимания на всякие выходки PM, у них тоже есть свои задачи и свои регламенты работы. Вполне возможно составление всяких характеристик тоже входит в их число. Вас это не должно как правило волновать, чем они занимаются.
  7. Следите, чтобы давление не было совсем сильным и градус адеквата сохранялся (мало ли будет ситуация описанная Barmaley).
  8. На самом деле работа в таком режиме может сильно повысить навыки, главное не перегореть от эмоциональных качелей, которые любят устраивать некоторые люди.

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

→ Ссылка