Розділ 2 — Проєктний менеджмент
5 речей про інжиніринг
На початку моєї кар'єри, було дуже мало ресурсів, які могли пояснити простою мовою про складні технічні концепти.
Сьогодні я хочу поділитися з вами 5 ключовими речами, які кожен менеджер має знати про інжиніринг, щоб керувати ефективніше.
1️⃣ Технічні основи
Ви повинні розуміти, як працює інтернет. Що трапляється коли ви натискаєте на ту, чи іншу кнопку. В якому форматі дані летять на сервер. Що сервер з ними робить. І як вони зберігаються.
Ключові слова: API, JSON, Endpoint, SQL, Client / Server relations, HTTP.
Ви не можете управляти тим, чого не розумієте.
2️⃣ Tech Stack вашої компанії
Чому важливо?
Обрання тих, чи інших технологій на пряму впливає на бізнес рішення. Наприклад, якщо ви обрали NoSQL базу даних, вам не потрібно робити міграції при розробці нових фіч. Це значно прискорить ваш робочий процес, але у вас можуть зʼявитися проблеми з якістю даних.
Старі та не популярні технології впливають на пошук нових інженерів, вам складніше їх шукати, ви більше їм платите.
3️⃣ Сенсетів точки вашого кодбейзу
Не увесь код вашого продукту написан однаково ідеально. Робота з деякими частинами вашого проєкту може викликати сильний біль у ваших девелоперів й затримки в делівері.
Уявіть що зміна тексту на якійсь сторінці вашої документації займає 2 дні, тому що ви обрали Gatsby, який потребує повний редеплой рішення, при будь-якій зміні контенту.
Так як це впливає на бізнес ви повинні про це знати. Зрозуміло, що не на все ви можете впливати як менеджер. Але це дасть вам більше інформації, для того, щоб краще менеджити процес розробки й очікування стейкхолдерів.
Як дізнатися? Запитайте вашу команду, де найбільша кількість технічного боргу. І які частини вашого продукту найбільш складні для правок.
4️⃣ Як вносити правки у продукт Не усі правки потребують уваги програміста. Деякі маленькі речі ви можете робити самостійно, й це пришвидшить ваш робочий процес.
Наприклад, вам потрібно зробити нову сторінку для публічної документації вашого продукту, чи новий блог пост. А ваш продукт працює зі статичним генератором сайтів. Ви може зробити її зробивши один pull-request з Markdown файлом ( до речі цей пост я пишу саме у цьому форматі ).
Чи змінити колір шрифту, чи округлення у форми. Ви можете це зробити самі, інколи це в десятки разів швидше ніж робота з програмістом. Якщо ви працюєте у стартапі, вам за це тільки скажуть дякую.
5️⃣ Процес вашого білда й деплойменту вашого продукту Написати код, це тільки половина діла — інша задача його доставити до ваших користувачів.
Те, як ваш продукт конпілюється й доставляється вашим користувачам, одна з найголовніших речей яка впливає на щоденну роботу менеджера. Якщо ви не розумієте цього, ви не можете бути впевненими що заделіверити у поставленні терміни. Чи взагалі ваші ченжи досягнуть вашого користувача.
Деякі ченжи десктопних додатків будуть потребувати у користувача реінсталяції додатку взагалі.
У деяких великих компаній та комплексних продуктів реліз включає зміни декількох команд одночасно, й це многоденний процес.
Розуміння цих речей дасть вам більше інформації для точного планування й делівері.
Як дізнатися? Запитати вашого тех. ліда чи архітектора. Подивитися на логи pull request’ів.