Очолюючи команду, я переважаю?

Я перебуваю в тому, що мені здається дуже дивним. Я "керівник команди" в ролі для конкретного проекту, старший інженер програмного забезпечення на посаді. У моїй команді у мене є 4 розробника, один з яких виконує подібну роль в іншому проекті, але зараз моєму надано пріоритет, тому він працює над моїм. У мене також є 2 тестери, один з яких - менеджер. Ще одним членом команди є "Представник замовника", який входить до складу повністю не пов'язаного відділу. У мене також є менеджер, який знаходиться безпосередньо над мною, і я вірю також і над менеджером тесту, який є частиною моєї команди ... але не дуже впевнений у цьому.

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

Сьогодні щось з’явилося, і результати коду я делегував одному з членів моєї команди, де його показали решті компанії під час нашої зустрічі Scrum-all-off. Особа представника замовника робить показ. Сьогодні було показано щось, з чим я дійсно не погоджувався, і ніхто ніколи навіть не питав мене, чи хочу я сказати те, що сталося. Коротше кажучи, для того, щоб надати користувачеві можливість відображати значення у звіті за такими способами ("doc" підрозділи, конструктивні блоки, округлені, а не округлені), вони надавали поля доступу для кожної перестановки. Таким чином, ми маємо значення в округлих док-одиницях, округлих конструкторських одиницях, необмежених док-підрозділах, необмежених конструкторських одиницях. Кожна запис, з якою користувач бажає працювати, має безліч таких значень, і кожна з них перестановлена ​​таким чином.

Я дуже ненавиджу це.

Люди, яким ми це показали, хочуть переконатися, що API, який ми використовуємо для звітів, такий самий, як і ми робимо такі речі, як експорт даних у Excel. На жаль, зараз ми набираємо цей оберт у напрямку, який, на мою думку, є насправді поганим.

Я трохи засмутився на наступній зустрічі, і я запитав двох людей, які це зробили: "Чому я не був причетний до цього рішення ??" Це питання, яке постійно виникає, і мені важко, мабуть, просто залучити людей до команди, яку я повинен вести, щоб запитати мене, чи хочу я брати участь. Іноді я цього не роблю і думаю, що все, що вони придумають, буде добре. Інший час я роблю. Якщо люди не запитують мене, хоча важко навіть знати, що щось відбувається, що потребує мого вкладу, і вони не дають мені такої можливості.

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

Сьогодні мій менеджер перед усіма (що, мабуть, частково і я винен у тому, що я виховував це) сказав мені, що я не можу брати участь у кожному рішенні і мені потрібно делегувати.

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

Питання в тому, чи я нерозумний?

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

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

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

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

Я ненавиджу слухати слово "дисципліна" від будь-кого в головній ролі. Дисциплінація (принаймні в цьому контексті) негативна і не є продуктивною. Робота з кимось (особисто, а не в обстановці для зустрічей), з'ясування чому вони щось зробили та надання альтернатив, якщо ви не згодні з запропонованими ними рішеннями - те, що потрібно зробити. Іноді ви виявите, що людина, з якою ви працюєте, має рацію, а ваш інстинкт кишечника неправильний. Чому? Вони витратили більше часу на цю конкретну проблему, ніж у вас.

Щось ще мене хвилює: "Я завжди думаю, що я правий". ІМО, це найгірше можливе ставлення від будь-якої ведучої. Ви, очевидно, повинні бути впевнені у своїх силах, але розумійте, що якщо ви не заглиблюєтесь у певну проблему, то більше разів ваші пропозиції виходять із тилу (незалежно від того, скільки досвіду у вас є) і не можете будь найкращим. Якщо хто - то , хто буде концентруватися на проблемі конкретного забезпечує альтернативу, то це ваша робота (ну, як і у них, в залежності від їх власного рівня досвіду) , щоб довести , чому ваш краще, а не просто сказати : «Я є провідним і Я завжди думаю, що я маю рацію ", і саме це ваше речення змушує мене повірити.

Загорнути його

Так, ви в деяких питаннях нерозумні, а в інших - ні. В якості ведучого я б очікував, що якщо є особливості або архітектурні зміни, то вони, принаймні, проходять повз вас.

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

Можливо, вас перевірять на управління, і якщо так, ви не вдається (що може не бути поганим; багато з нас є хорошими розробниками і були б поганими менеджерами, і я хотів би скоріше програмувати, ніж керувати програмістами).

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

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

Правильний спосіб розібратися з чимось подібним - це приватно, спочатку запитавши розробників, чому вони зробили показ саме цього. Не на зустрічі, і не з того, щоб висловити перед собою, що ви праві, і вони помиляються (навіть якщо ви маєте рацію і помиляєтесь). Дайте їм можливість пояснити. Це не означає, що ви повинні піти з їх рішенням; ви, зрештою, технічний провід. Це означає, що вам потрібно надати їм причини зробити це по-своєму, і вам слід вирішити будь-які фундаментальні проблеми, які виявляються під час цієї приватної зустрічі.

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

Не сприймайте це особисто

Це зусилля команди. Ваш технічний керівник, не єдиний хлопець проекту. Ви повинні зосередитись на тому, щоб команда вчилася на помилках чи зміні процесу.

Ведіть і вчіться

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

Огляд перед презентацією клієнта

Якщо ваш керівник проекту, чому ви не переглянули функцію та реалізацію до її представлення?

Якщо це неправильно, виправте це

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

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

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

Тоді ви можете почати працювати над очищенням функції, як тільки диски будуть призначені повторно.

редагувати> І ні, я не думаю, що ти переживаєш. Їх робота закінчується твоєю дупою.

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

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

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

Я занадто часто так емоційно відчуваю:

 I of course think I'm right....I always do. 

але я маю сенс інтелектуально знати, що я іноді помиляюся. Я також знаю, коли вибирати бій - ви не можете сперечатися з усім, а іноді несподівана згода з вашого боку може творити чудеса.

Що таке справжній лідер?

Хтось, хто може звільнити підлеглого, будь-який підлеглий. (але не потрібно наймати нову)

Іноді більшість людей "позначаються" як керівника якогось проекту, але, не маючи вогню когось, то це більше "керівництво" / "вчитель", ніж справжній керівник.

Але знову ж таки, може статися, що ви можете бути лідером команди, але не вести свій поточний проект. Найгірший випадок , коли клієнт веде проект. На даний момент, якщо проект вийде з ладу (і він буде невдалий), це не є вашою відповідальністю.

І найгірший випадок, коли існують два лідери проекту.

Як військовий, командування - це все (не настільки радикально, як "помер за проект", але досить близько). З цього приводу ваш менеджер порушив ваш статус, знизив мораль "своїх" людей і зовсім не допомагав.

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

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

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

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

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

Далі ви публічно підірвались, вам потрібно вибачитися публічно. Це допоможе вам повернути собі репутацію.

Тоді вам потрібно відвести кожного від людей у ​​приватний бік і сказати їм наслідки для їх подальшої поганої поведінки (як тільки ви змусите свого менеджера погодитись, щоб він міг надати їм наслідки). Публічна похвала і підтримка, приватна критика повинні бути вашим правилом. Також вам може знадобитися частіше спілкуватися з ними поза межами зустрічей групи, щоб вони не могли вас засліпити.

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