Как да бъдеш ИТ инженер, който продуктовият/проектният мениджър да не мрази

Да бъдеш инженер, когото ПМ-ите не мразят:

• Бъдете отговорни със качеството на доставения код
• Не превръщайте продуктовия мениджмънт в свой QA екип или в мениджър на проекти
• Не бъркайте техническите познания с интелигентност

Бъдете отговорни със качеството на доставения код

Инженерите имат едно нещо, което създава много уникален баланс на мощността: те изпращат кода.

Инженерите могат да направят някои неща без PM или дизайн, но PM и дизайнът не могат да реализират бизнес стойност чрез продукт, без инженерите да го изградят.

Зависимостта от изпращане на код е много мощна за инженерите. Когато тази власт се използва и злоупотребява, нещата се объркват. Най-простият вариант на лошо поведение в това отношение е да бъдете мързеливи и да карате PM да ви питат за неща - актуализации, информация, мнения. Става още по-лошо, ако не сте любезни да отговорите. Абсолютно най-лошата версия на това изглежда като родители и тийнейджъри - PM, които искат информация и инженери, които се държат така. Моля, не правете това.

Инженери, за да бъдете добър партньор на PM:

• Не карайте премиерите да ви преследват за информация. Бъди проактивен.
• Когато PM ви поискат информация, отговорете бързо и любезно (и ако имате опит, научете ги как да задават въпроси възможно най-ефективно и асинхронно).
• Не се съгласявайте и не се ангажирайте, ако е необходимо, но ако някога стачкувате, ще разрушите отношенията си непоправими.
• Не превръщайте продуктовия мениджмънт в свой QA екип или ръководител на проекти

Ролята на PM понякога може да има двусмислени граници. Точно като инженерните мениджъри, те често решават различни видове проблеми - независимо от нуждите на екипа. Тази двусмисленост може да доведе до увеличаване на обхвата на отговорностите, често на най-малко бляскавите места. Като отговорен инженер и добър партньор трябва да избягвате това да се случва.

Често срещана област, в която нещата се объркват, е QA. В много гъвкави екипи PM-ите в крайна сметка извършват User Acceptance Testing или проверка на изискванията, преди билетите да бъдат пуснати на живо. Понякога екипите могат бавно да се придвижат към състояние, в което User Acceptance Testing открива все повече и повече грешки (вместо просто да проверява изискванията). Обичайният начин, по който това се случва, е, ако инженерният екип е много по-малко натоварен от PM и той знае как да тества по-добре от инженерите. Във всеки случай PM, действащ като QA, не е здравословно състояние.

Ако PM хваща много грешки в User Acceptance Testing, инженерните екипи трябва да преоценят своята стратегия за QA и да коригират проблема възможно най-скоро.

Друго място, на което инженерите могат да разчитат прекалено много на PM, е управлението на проекти. Тъй като PM са най-активни в началото и в края на проектите - предават волана на инженерите за изпълнение и го връщат обратно, когато кодът е завършен, за да се достави надолу по веригата - често може да има неясноти относно това колко PM трябва да управляват проекти в средата . 

Инженерните мениджъри, ръководителите на проекти или техническите ръководители трябва да управляват инженерното изпълнение, а не PM.

Не бъркайте техническите познания с интелигентност

Един от основните грехове на инженерното сътрудничество е приемането, че техническите знания са равносилни на цялостна интелигентност. Разбира се, вашият ПМ може да не разбере отстраняването на купища грешки които направихте вчера, но не позволявайте това да ви минава през ума. Не бъдете глупак като цяло, но просто внимавайте да не позволите на техническата мощ да ви подтикне да мислите, че сте по-умен от всеки друг.

Ако имате нужда от подсказка как да се смирите, просто си представете, че трябва да обясните конкурентните пропуски на вашия продукт, партньорската среда и скорошната траектория на приходите чрез powerpoint на среща с изпълнителния екип, както често правят ПМ-ите.

Обяснете стойността на технологичния дълг по начин, който е лесен за разбиране

Едно от местата, в които ПМ-ите и инженерите могат да си сблъскват главите, е приоритизирането на технологичния дълг. Особено когато няма изкуствени пропорции, които са разпределени за всеки, ПМ-ите често искат да разберат защо има технологичен дълг, а инженерите понякога могат да се върнат към „просто трябва да си инженер, за да го получиш“. По-често, отколкото не, това обяснение казва повече за разбирането на инженера за технологичния дълг, отколкото за разбирането на ПМ-а. Приоритетизирането на технологичния дълг трябва да бъде завладяващо, очевидно и прозрачно – ако не е, рискувате да се гмурнете в заешка дупка на рефакторинг на код, без всъщност да се фокусирате върху това защо има значение.

Така че, бъдете добър партньор, не позволявайте на вашия ПМ да започне да прави QA, обяснете границите на вашия технологичен дълг, бъдете добре и просперирайте.