Як вести проект розвитку без технічної експертизи

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

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

Що мені робити, і як мені уникнути того, щоб стати керівником проекту, який я ненавидів, коли я розвивався?

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

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

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

Управління може, залежно від рівня кваліфікації ваших розробників, означає їх консультування, коли вони цього вимагають. "Ви заглянули в Spring.NET?" (зауважте, відсутність там інструкції) - ідеально добре сказати. Крім того, "Google навколо, подивіться, що робить інший світ, ми не вперше зіткнулися з цією проблемою".

У деяких аспектах, як досвідчений розробник Java, ви можете опинитися в кращому становищі, ніж більшість з них. Більшість фреймворків і технологій Java мають аналогічний еквівалент у .NET. Таким чином, вам не потрібно говорити "Ось найкраще використовувати", ви можете сказати: "Я використовував це в Java, ви знаєте .NET еквівалент?"

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

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

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

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

Ви не вибрали свої навички кодування C #, і якщо ви з самого початку не будете писати код, не має значення, знаєте ви C # чи ні. Вам потрібно почати думати на більш високому рівні:

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

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

У будь-якому випадку, навчіться бути ефективним, працюючи в C # якомога швидше. Просто пам’ятайте, що ваша роль полягає в тому, щоб проглянути повний синтаксис і деталі рамки і переглянути більшу картину.

Візьміть руки на підхід. Почніть із захоплення собі простого букваря C # та напишіть якийсь код. Спробуйте кілька основних речей, які б ви могли знати із зав'язаними очима іншою мовою.

Прочитайте про стиль програмування та конвенцію. У будь-якому випадку ви повинні знайти це частково у вашому ґрунтовці, але ви також можете використовувати такі продукти, як StyleCop та Resharper, щоб застосовувати правила стилю, які вам не знайомі. Це ефективно навчить вас дуже швидко робити речі загальноприйнятим способом, щоб уникнути проблем зі складанням вашого програмного забезпечення.

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

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

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

Це здається, що тут є кілька проблем.

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

Ви керівник команди чи головний розробник? Провідний розробник також робить зовсім небагато дизайнерських та конструкторських робіт. Тож єдиний спосіб цього - просто збитись та вивчити нові технології .

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

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

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

Удачі!

Можливість з'являється раз у раз. Зроби це .. Я б сказав, спробуйте засвоїти ази C #. Отримайте підручник з Інтернету, спробуйте попрацювати над ним. спочатку було б важко вивчити нову концепцію, пізніше, коли перше завдання виконано, ви будете мати певну впевненість у цьому.

Подумайте позитивно, Спробуйте прийняти важке завдання, Налагодьте власний код і впевнений, що ви його освоїте.

Не втрачайте своїх можливостей.

Я думаю, якщо у вас є хороша група розробників .Net, в колективі є багато знань, до яких, можливо, потрібно скористатися, щоб розпочати роботу. Є багато подібності між Java та .Net, що те, що ви вже знаєте, може насправді застосовувати більше менш безпосередньо. Важливо знати, що важливо, щоб отримати право на цей проект та пов'язані з цим ризики. Спілкуйтеся зі своєю командою якомога частіше. Практика розробки програмного забезпечення розвивається протягом усього проекту, тому може бути важко мати «найкращу практику» на самому початку проекту.

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

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

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

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

Завантажте їх робочий код. Читати.

З’ясуйте, які інструменти вони використовують. Використовуйте їх.

З’ясуйте, як створити та випустити проект з відкритим кодом. Побудуйте його та відпустіть.

Проект з відкритим кодом (із кількістю учасників) буде ілюструвати кращі практики.

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

Правда.

Навчіться у спільноті з відкритим кодом.