Не хочу бути менеджером

Така історія: я — звичайний мідл девелопер, спеціалізуюсь на iOS та Android. В одній із компаній, в яких я працював, проекти були невеликі — по 1-2 дівелопера на проект. Прожект менеджерів не було як таких, були продукт менеджери. Відповідно функції прожект менежера розділялись між девелопером та продукт менежером.

До прикладу, на девелопера покладалися такі функції:
— Побудова списку тасків за реквайрментами
— Оновлення прожект плану
— Розбір тасків від замовника в процесі девелопменту

Отже, щодо такого підходу, відомі мені плюси:
— економія грошей
— відсутність додаткової ланки
— розвиток самостійності дівелопера

Мінуси:
— більше навантаження на дівелопера та продукт менежера

Все ж особисто мені цей підхід був не до вподоби, у фріланс я не квапився, суттєвої різниці у зп не відчував, а щодо більшої близькості до клієнта, часом це було навіть в мінус. Отже плюсів цього підходу я не відчував, а от щодо навантаження, це було критично, зважаючи що я — давншифтер.

А як ви ставитесь до такої практики?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Це поширена практика. «Зроби вигляд, що це твій проект, чи, навідь, твій стартап. Я потім тобі подякую.» Звичайне жлобство та економія. Хоча бувають здебільшого американські замовники, яким не шашечки, а саме їхати. У таких і сайти інколи «помаранч на рожевому». Нічого для них страшного: клієнти ходять, усе добре.
Тобто, якщо з Вас не _вимагають_ функцій манагера, то таке не є зле. Але якщо мусите сам собою керувати та й ще про це звітувати, то нафіг-нафіг

Достаточно часто бывает так, что разработчику предоставляется шанс стать техлидом или тимлидом, реже ПМом. Многим нравится, многим нет, все индивидуально.
Не нравится — зачем мучаться? Откажись от управленческих функций, вернись к разработке, получай удовольствие от работы, тем более что деньги практически те же, а проблем меньше.

Якщо тебе такий стиль роботи дуже підхарює, спробуй пошукати щось нове, де ти будеш просто девелопером. Позитив цієї роботи в тому, що маючи декілька років такої практики і при наявності хорошої англійської, можна ходити на співбесіди на ПМа.
Закладай в естімейти тасків менеджерські моменти, час спілкування з клієнтом і все таке, якщо керівництво почне обурюватись, явно вкажи, що тебе це відволікає від розробки та значно розтягує час виконання задачі.

Погана практика. 1 людина не може бути одночасно і хорошим виконавцем і менеджером. Якість результатів буде падати. На крайній випадок можна ж наняти менеджера віддалено на гнучкий графік...

Согласен. Я думаю аналогично по iOS и Android, надо что одно выбрать и в нем стать мастером, гуру.

А у фрилансеров получается.

Слышал пословицу «Кто везет, того и погоняют»? Или иначе говоря: кто хорошо работает — на того больше работы и наваливают.
С точки зрения начальника — это абсолютно правильно. Начальник стремится по-максимуму делегировать свои обязанности подчиненным. Во-первых это его разгружает от неприятной рутины, а во-вторых «развивает» подчиненных и теоретически приближает час, когда они сами станут начальниками.
Я вижу тут несколько стратегий поведения:
1) Карьерист: делать все что дают и даже стараться угодить начальнику еще больше. С этой позиции бесполезный отчет, написанный за начальника, поможет в карьере больше, чем 10500 строк полезного и правильного кода, который начальник не смотрит.
2) «Жлоб»: формально девелоперу платят за код, а не за исполнение чужих обязанностей. Хороший специалист, разумеется, может и готов играть несколько ролей на проекте и брать на себя больше обязанностей — но за дополнительную оплату.
3) «Дауншифтер» (это про меня): за карьерой или премиями не гонюсь, предпочитаю делать свою работу которая мне интересна и в которой я специалист. Наклоняют делать «левые» задачи и брать на себя чужие обязанности? Я не буду отказываться на отрез, но поясню что выполнение непривычных задач потребует от меня много времени на обучение и результат может быть по пословице «первый блин комом».
Лично у меня подход к работе следующий. То, что мне интересно я готов делать в свободное время и бесплатно. То, что мне не интересно, но нужно — я буду делать в рабочее время не перенапрягаясь. От ненужной и тупой работы я постараюсь откосить под любым предлогом. Если же уже заставили сделать то, что не хотел — быстро сделаю какую-нибудь херню «на отвали» и остальное время буду изображать видимость работы.

На тебя будут вешать всё больше и больше, твоя задача не поддаваться. Пойди и скажи — я эту работу делать не хочу, она меня демотивирует. Я тебя прекрасно понимаю, дай понять, что эта работа тебе не нравится, дальше смотри по обстановке, делать то, что не нравится на тебя будет давить каждый день и в конце-концов тебе не будет хотеться на работу ходить вообще.

Выбирай любой вариант — всё равно пожалеешь.

А Ви мали досвід такої роботи?

Так, але в майже не айтішній галузі. Загальні проблеми схожі, але деталі порадити не можу — вони дуже відрізняються.

Звичайно, я дуже багато спілкувався з менеджерами по розробці програмного забезпечення, але цей досвід через треті руки бажано не передавати. Ми ж на ДОУ, спілкуйся з потрібними людьми сам.

Єдине що можу гарантувати — менеджмент в деталях дуже різний залежно від проекту, його стадії, підпорядкованості до проектів замовника. Тому майже ніякий досвід тобі не допоможе, якщо не опишеш ситуацію в деталях (цифри, дати, ризики). Зазвичай люди таким не діляться, та й замовник навряд чи дозволяє. Через це матимеш надзвичайно великий ризик найняти не того менеджера. А менеджер що має досвід в багатьох проектах різних типів — тобі не по кишені.

Проте є один лайфхак: В різний час доби люди думають зовсім по різному. Стопудово є такий час, коли кодити важко і майже безрезультатно. А от менеджмент в цей час під легко. Так, це збільшить тривалість робочого часу, але ефективно збереже кошти і... робочий час на спілкування зі стороннім менеджером.

Підписатись на коментарі