Проект-менеджерам (і тим, хто мріє стати начальником), присвячується.
Писати тонни коду складно, а керувати людьми ще складніше! Так що вам просто необхідна ця книга, щоб навчитися робити те й інше.
Чи можна поєднати прикольні історії та серйозні уроки? Майкл Лопп (також відомий у вузьких колах як Рендс) це вдалося. На вас чекають вигадані історії про вигаданих людей, які мають неймовірно корисний (хоч і вигаданий) досвід. Саме так Рендс ділиться своїм різноманітним, часом дивним досвідом, здобутим за роки роботи у великих IT-корпораціях: Apple, Pinterest, Palantir, Netscape, Symantec та ін.
Ви проект-менеджер? Або хочете зрозуміти, чим ваш чортів бос займається весь день? Рендс навчить вас виживати в Токсичному Світі Надутих Індиків та процвітати серед загального божевілля дисфункціонально-яскравих людей. У цьому дивному співтоваристві маніакальних розумників є ще дивніші істоти — управлінці, які через містичний організаційний ритуал отримали владу над планами, думками та банківськими рахунками багатьох людей.
Ця книга не схожа на жодний манускрипт з менеджменту чи лідерства. Майкл Лопп нічого не приховує, він просто розповідає все як є (можливо, не всі історії варто було б розголошувати: Р). Але тільки так ви зрозумієте, як вам вижити з таким босом, як керувати гіками та нердами та як уже довести до хепі-енду «той грібаний проект»!
Уривок. Інженерна ментальність
Роздуми на тему: чи потрібно продовжувати писати код
У книзі Рендса про правила для керівників є дуже короткий перелік сучасних менеджерських must-do. Лаконічність цього переліку випливає з того факту, що поняття «must» — це абсолют, а коли мова заходить про людей, то абсолютних понять стає дуже мало. Вдалий метод керівництва одним співробітником стане справжньою катастрофою для іншого. Ця думка і є першим пунктом менеджерського «must-do» списку:
Залишайся гнучким!
Вважати, що ви вже знаєте, — дуже погана ідея. У ситуації, коли єдиним незмінним фактом є той факт, що у світі відбуваються постійні зміни, гнучкість стає єдиною вірною позицією.
Парадоксальним чином другий пункт переліку напрочуд негнучкий. Однак цей пункт — мій особистий фаворит, бо я вважаю, що саме він допомагає створити фундамент для менеджерського зростання. Цей пункт говорить:
Припини писати код!
Теоретично, якщо ви хочете бути керівником, ви повинні вчитися довіряти тим, хто працює на вас, і повністю передати їм написання коду. Ця порада зазвичай важко «перетравлюється», особливо новоспеченими керівниками. Ймовірно, однією з причин, через яку вони стали керівниками, є їхня продуктивність у справі розробки, і коли все йде наперекосяк, їхня перша реакція — вдатися до навичок, у яких вони повністю впевнені, тобто до свого вміння писати код.
Коли я бачу, що новий керівник «опускається» до написання коду, я говорю йому: «Ми знаємо, що ти вмієш писати код. Запитання в іншому: чи вмієш ти керувати? Ти більше не відповідаєш за себе одного, ти відповідаєш за всю команду цілком; і я хочу бути впевненим у тому, що ти зможеш зробити так, щоби твоя команда вирішувала проблеми самостійно, без того, щоб тобі самому доводилося писати код. Твоє завдання полягає в тому, щоб з'ясувати, як масштабувати себе. Я хочу, щоб ти не був одним, я хочу, щоб таких, як ти, було багато».
Хороша порада, правда? Масштаб. Менеджмент. Відповідальність. Такі модні словечки. Шкода, що порада невірна.
Невірний?
Ага. Порада невірна! Не те щоб абсолютно невірний, але досить невірний, щоб мені довелося зателефонувати деяким колишнім колегам і вибачитися: «Пам'ятаєш моє улюблене твердження про те, що ти повинен припинити писати код? Воно неправильне! Так… Знову починай програмувати. Почни з Python та Ruby. Так, я серйозно! Від цього залежить твоя кар'єра!
Коли я починав кар'єру розробника програмного забезпечення в Borland, я працював у команді Paradox для Windows, а це була величезна команда. Лише одних розробників програми було 13 осіб. Якщо додати людей з інших команд, які теж постійно працювали над ключовими технологіями для цього проекту, такими як основний движок бази даних та основні послуги програми, то виходило 50 інженерів, безпосередньо зайнятих розробкою цього продукту.
Жодна інша команда, в якій я коли-небудь працював, навіть не наблизилася до таких розмірів. Насправді, з кожним роком кількість людей у команді, в якій я працюю, поступово скорочується. Що ж відбувається? Невже ми, розробники, колективно стаємо все розумнішими і розумнішими? Ні, ми просто розподіляємо навантаження.
Чим розробники займалися останніх 20 років? За цей час ми написали фігову хмару коду. Море коду! Ми написали так багато коду, що вирішили: непогано б усе спростити та перейти на відкритий вихідний код.
На щастя, завдяки інтернету цей процес став максимально простим. Якщо ви розробник, то можете перевірити це прямо зараз! Пошукайте своє ім'я в Google або Github, і ви побачите код, про який ви давно забули, але який може знайти кожен, хто забажає. Страшно, правда? Ви не знали, що код живе вічно? Так, він живе вічно.
Код живе вічно. А хороший код не тільки живе вічно, він росте, тому що ті, хто його цінують, постійно дбають про те, щоб він не втрачав своєї свіжості. Ця купа високоякісного коду, що міститься в хорошому стані, допомагає скоротити середній розмір інжинірингової команди, тому що дозволяє нам фокусуватися не на написанні нового коду, а на вже існуючому коді і виконувати роботу з меншою кількістю залучених людей і за більш короткі терміни.
Цей ланцюжок міркувань звучить гнітюче, проте ідея полягає в тому, що всі ми — це лише купка інтеграційних автоматів, які використовують клейку стрічку для того, щоб з'єднувати між собою різні частинки існуючих речей для створення трохи іншої версії того ж самого. Це класичний хід думок вищого керівництва, що обожнює аутсорсинг. «Це може зробити будь-хто, хто вміє користуватися Google і хто має клейку стрічку! Тоді навіщо ми платимо купу грошей нашим автоматам?
Ми платимо цим типам із керівництва реально великі гроші, а вони думають таку нісенітницю. Ще раз: моя ключова ідея полягає в тому, що на нашій планеті безліч геніальних та дуже старанних розробників; вони справді геніальні та старанні, хоча й не витратили жодної хвилини на сидіння в акредитованих університетах. О так, зараз таких стає дедалі більше!
Я не пропоную вам почати турбуватися за своє місце лише тому, що деякі геніальні товариші нібито на нього полюють. Я пропоную вам почати турбуватися за нього, тому що еволюція розробки програмного забезпечення, можливо, рухається швидше, ніж ви. Ви працюєте вже десять років, з них п'ять років як керівник, і думаєте: «Я вже знаю, як розробляється софт». Так, ви знаєте. Бувай…
Припиніть писати код, але…
Якщо ви наслідуватимете мою початкову пораду і перестанете писати код, то одночасно ви за власним бажанням перестанете брати участь у процесі створення. Саме з цієї причини я не особливо активно використовую аутсорсинг. Автомати не виробляють, вони виробляють. Добре розроблені процеси дають змогу економити багато грошей, проте вони не привнесуть у наш світ нічого нового.
Якщо у вас невелика команда і вона робить багато за невеликі гроші, ідея припинити писати код здається мені поганим кар'єрним рішенням. Навіть у компаніях-монстрах з їх нескінченними регламентами, процесами та політикою ви не маєте права забути, як самостійно розробляти софт. А розробка софту постійно змінюється. Вона змінюється прямо зараз. У вас під ногами! Цієї самої секунди!
У вас є заперечення. Розумію. Послухаймо.
«Рендсе, я на шляху до директорського крісла! Якщо я продовжу писати код, ніхто не повірить, що я можу рости».
Я хочу запитати вас ось про що: відколи ви сіли у своє крісло «Я скоро стану директором!», чи помічали ви, що сфера розробки софту змінюється навіть у межах вашої компанії? Якщо ваша відповідь «так», то я поставлю вам інше питання: як саме вона змінюється і що ви збираєтеся зробити у зв'язку з цими змінами? Якщо на моє перше запитання ви відповіли «ні», то вам потрібно пересісти в інше крісло, тому що (зуб даю!) сфера розробки софту змінюється цієї самої секунди. Як ви взагалі збираєтеся рости, якщо ви повільно, але правильно забуваєте, як розробляти софт?
Моя порада полягає не в тому, щоб доручити собі реалізацію тонн функцій для наступного продукту. Потрібно постійно вживати заходів для того, щоб залишатися в курсі того, як ваша команда створює софт. Ви цілком можете робити це і як директор, і як віце-президент. Щось ще?
«Уф, Рендсе! Але ж хтось має бути арбітром! Хтось має бачити загальну картину. Якщо я писатиму код, то я втрачу з уваги перспективу».
Ви, як і раніше, повинні залишатися арбітром, ви, як і раніше, повинні транслювати рішення, і ви, як і раніше, щоранку понеділка повинні чотири рази обходити всю будівлю разом з одним зі своїх інженерів, щоб протягом 30 хвилин слухати його щотижневу тираду «Ми всі приречені !». Але крім того, ви повинні зберігати в собі інженерний спосіб мислення, а для цього вам не обов'язково бути програмістом на повну ставку.
Мої поради щодо збереження інженерної ментальності:
- Використовуйте середовище розробки. Це означає, що ви повинні бути знайомі з інструментарієм своєї команди, включаючи систему складання коду, контроль версії та мову програмування. В результаті цього ви будете володіти мовою, якою ваша команда користується, коли говорить про розробку продукту. Це також дозволить вам продовжувати використовувати ваш улюблений текстовий редактор, який відмінно працює.
- Ви повинні вміти намалювати докладну архітектурну схему, що описує ваш продукт, на будь-якій поверхні та у будь-який час. Зараз я не маю на увазі спрощений варіант із трьома осередками та двома стрілочками. Ви повинні знати детальну схему продукту. Найскладнішу. Не просто якусь симпатичну схему, а схему, яку важко пояснити. Це має бути карта, придатна для повного розуміння продукту. Вона постійно змінюється, і ви завжди повинні знати, чому відбулися ті чи інші зміни.
- Візьміть він реалізацію однієї з функцій. Я буквально здригаюсь, коли пишу це, тому що цей пункт таїть у собі багато прихованих небезпек, але я дійсно не впевнений у тому, що ви зможете виконати пункт №1 та пункт №2 без того, щоб взяти на себе реалізацію хоча б однієї функції . Завдяки самостійній реалізації однієї з функцій ви не тільки братимете активну участь у процесі розробки, це також дозволить вам періодично перемикатися з ролі «Керівника, що відповідає за все» на роль «Людини, що відповідає за реалізацію однієї з функцій». Ця скромна і невибаглива позиція нагадуватиме вам про важливість маленьких рішень.
- Я все ще весь тремчу. Здається, хтось уже репетує на мене: «Керівник, який взяв на себе реалізацію функції?! (І я з ним згоден!) Так, ви, як і раніше, залишаєтеся керівником, а значить, це має бути якась невелика функція, добре? Так, у вас, як і раніше, багато справ. Якщо ви ніяк не можете взяти на себе реалізацію функції, то у мене для вас запасна порада: займайтеся усуненням деяких багів. У цьому випадку ви не будете відчувати радості творення, але у вас буде розуміння того, як створюється продукт, а значить, ви ніколи не залишитеся без справ.
- Напишіть модульні тести. Я все ще роблю це на пізніх етапах виробничого циклу, коли люди починають божеволіти. Розглядайте це як чек-лист працездатності продукту. Робіть часто.
Знову заперечення?
«Рендс, якщо я писатиму код, то я збиватиму з пантелику свою команду. Вони не знатимуть, хто я – керівник чи розробник».
Добре.
Так, я сказав: "Добре!" Я радий, що ви вважаєте, що зможете спантеличити свою команду лише тим, що плаваєте в ставку розробників. Тут все просто: межі між різними ролями у сфері розробки софту зараз дуже розмиті. Хлопці, які займаються інтерфейсом користувача, роблять те, що можна в цілому назвати програмуванням на JavaScript і CSS. Розробники все більше дізнаються про проектування взаємодії з користувачем. Люди спілкуються один з одним і дізнаються про помилки, про злодійство чужого коду, а також про те, що не існує жодної поважної причини для того, щоб керівник не міг брати участь у цій масивній, глобальній, перехресно запилюваній інформаційній вакханалії.
Крім того, ви ж хочете бути частиною команди, що складається з складних елементів, що легко замінюються? Це не просто зробить вашу команду більш моторною, це дасть кожному її члену можливість бачити продукт і компанію з різних точок зору. Як ви зможете ще більше зауважити Френка, того спокійного хлопця, відповідального за компонування, якщо не після того, як побачите просту елегантність його складальних скриптів?
Я не хочу, щоб у вашій команді панували плутанина та хаос. Навпаки, я хочу, щоб комунікація у вашій команді стала більш ефективною. Я впевнений у тому, що якщо ви берете участь у створенні продукту і працюєте над функціями, ви будете ближче до своєї команди. І що ще важливіше — ви будете ближчими до постійних змін у процесі розробки софту в межах вашої організації.
Не переставайте розробляти
Одна моя колега з Borland одного разу вербально атакувала мене за те, що я назвав її кодером.
«Рендс, кодер - це безмозка машина! Мавпа! Кодер не робить нічого важливого, окрім написання нудних рядків марного коду. Я не кодер, я розробник софту!
Вона мала рацію, вона б зненавиділа мою початкову пораду новоспеченим керівникам: «Припиніть писати код!» Не тому, що тим самим я ніби припускаю, що вони кодери, а більше тому, що я проактивним чином пропоную їм почати ігнорувати одну з найважливіших частин їх роботи - розробку ПЗ.
Отже, я допрацював свою пораду. Якщо ви хочете бути хорошим керівником, то ви можете припинити писати код, але…
Будьте гнучкими. Пам'ятайте, що означає бути інженером і не переставайте розробляти софт.
Про автора
Майкл Лопп — ветеран у галузі розробки програмного забезпечення, який ще не покинув Кремнієву долину. За останні 20 років Майкл встиг попрацювати в різних інноваційних компаніях, включаючи Apple, Netscape, Symantec, Borland, Palantir, Pinterest, а також взяти участь у стартапі, що повільно сплив у небуття.
Крім роботи Майкл веде популярний блог про технології та менеджмент під псевдонімом Рендс, де обговорює з читачами ідеї у сфері менеджменту, висловлює занепокоєння з приводу постійної необхідності тримати руку на пульсі і пояснює, що, незважаючи на щедрі нагороди за продукт, що створюється, ваш успіх можливий тільки завдяки вашій команді. Блог можна знайти за посиланням .
Майкл живе зі своєю родиною у місті Редвуд, штат Каліфорнія. Він завжди знаходить час на те, щоб покататися на гірському велосипеді, пограти в хокей і випити червоного вина, оскільки бути здоровим важливішим, ніж зайнятим.
» Докладніше з книгою можна ознайомитись на
»
»
Для Хаброжителів знижка 20% купона Managing Humans
За фактом оплати паперової версії книги на e-mail надсилається електронна версія книги.
PS: 7% вартості книги піде на переклад нових комп'ютерних книг, список зданих у друкарню книг .
Джерело: habr.com