Як мені досягти успіху як провідний розробник? [на утриманні]

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

Що слід пам’ятати під час управління цим проектом? Як я можу переконатися, що все поводиться так, як слід?

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

• Зрозумійте, яка мета проекту.

Часто мова йде не про всі функції, які були внесені в проект. Йдеться про основний набір функціональних можливостей, який відповідає на потреби бізнесу. Завжди майте це на увазі, оскільки це ваша головна мета.

• Розбивка того, що потрібно зробити для виконання завдань. Зрозумійте залежності між ними.

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

• Зрозумійте, що таке відкриті питання чи неоднозначності проекту.

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

• Бізнес ненавидить сюрприз.

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

• Щодня переходьте на велику картину.

Вам слід щодня на годину переглядати велику картину щодня. Задайте собі питання. Що було завершено? Що залишилося зробити? Які відкриті запитання? Яка мета? Ви повинні мати змогу надати комусь детальний статус проекту, коли він запитає.

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

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

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

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

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

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

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

• Зразки роботи команди - спробуйте трохи ознайомитися з роботою кожного. Прочитайте їх код, запустіть їх функції, спробуйте їх тестові справи. Не націлюйтеся на 100% роботи кожного, спробуйте трохи взяти вибірки у всіх. Надайте їм відгуки, а також відставте сильні та слабкі сторони в команді.

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

• Періодично переглядайте ресурси команди - люди проглядатимуть, коли наявний раніше ресурс стане недоступним, але перевірять на предмет невідомих болю. Де твої точкові точки? Чи є нові інструменти, які були б корисні мати? У більшості команд є хлопець, якого я вважаю інструментом мисливця, який завжди працює над останніми та найкращими гаджетами. Збалансуйте розмови між мисливцем за інструментами та GuyWhoHatesEverythingNew, щоб знайти наступну точку еволюції. Інструменти включають все - SW, HW, фізичний простір, навчальні ресурси.

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

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

• Перегляньте вартість та графік- Наскільки ймовірно, що ваша команда буде означати свій поточний термін? Як щодо наступного терміну? Яка швидкість опіку ваших витрат? Які великі майбутні покупки ви ще не заплатили? Що залишилося від вашого бюджету? Деталі змінюються залежно від того, як ви здійснюєте фінансове відстеження, але навіть у дуже неформальній компанії ви повинні мати уявлення як про кількість днів / тижнів / місяців бюджету, які ви залишили, так і термін виконання поточного продукту. Десь якось краще хтось планував "скільки людей нам потрібно для цієї роботи?" і "чи можемо ми дозволити собі їх виплату наступного місяця / кварталу / року?". Вам потрібно знати ці цифри та мати наступні кроки. Вам потрібен кристально чіткий план на наступний тиждень, який ви могли б пояснити прямо зараз, якщо хтось зайшов і запитав. Вам потрібен досить хороший план на наступний місяць, це зміниться лише в 2-3 місцях, коли реальність потрапить. Вам потрібен схематичний план на чверть і загальний відбіток голови на рік. Минулого, навіть у величезному проекті, цифри - це просто цифри. Слухайте їх, але розумійте, що в крові ніхто не підписався.

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

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

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

Прочитайте цю книгу: Пастушні коти: Підручник для програмістів, які ведуть програмістів

Деякий час тому я обдарував цю книгу для свого шефа, і він сподобався. Коли я його читав, здавалося, що він знає, про що говорить. І це так. Автор розповідає про власний досвід. Чи не збірка "простих істин" менеджера - це слова колишнього програміста. І слід розуміти, що це був його досвід, але ваш може бути інакший. Отже, на деякі речі слід дивитися критично. "Менеджер більше не може бути програмістом - це важливо".

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

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