- Ваші здобутки на попередньому проекті?
- Клієнт з Швеції вивчив фразу “Slava Bogu” вже після першого релізу!
Місячні архіви: Грудень 2021
Шанси бути керівником для програмістів
Вміння круто писати код без жодного досвіду роботи з людьми та відсутністю soft skils АБО вміння круто керувати іншими людьми, досвід вирішення бізнес питань без знання деталей розробки ПЗ – все це не означає що ви зможете керувати розробниками. В обох випадках більше ймовірність для провалу.
Істина десь посередині – якось вмієте писати код та розумієте процес, рука тягнеться до поліпшення організації, але ще не дуже розумієте що робити з soft skills. Ви бачите як ви імпульсивно тягнетесь до комунікацій, до людей, але все ще працюєте з софтом. У такому випадку шанс стати добрим керівником для програмістів значно кращий.
Менеджер програмістів та вміння розробляти код
Чи має керівник програмістів який ставить оперативні задачі вміти розробляти код? Це дуже політичне питання, існують полярні думки та варіанти та можна витрати купу часу на it depends. Надалі не буде цього, буде проста окрема думка.
Наразі швидка відповідь – дуже бажано вміти писати код або власноруч створювати програмне забезпечення.
Читати даліКонтроль задач
Питання контролю задач важливо як для розробника, так і для менеджера який постави задачу. Звісно що існує багато дуже простих задач – але навіть вони мають свої проблеми. Розгляньмо типові проблеми. (майже) Всі поради нижче мають застосовувати розробник та менеджер.
Читати даліМатематична збіжність або кроки до (не) звільнення

Якщо вас бісить певний тип проблем з розробником та ви згарячу бажаєте звільнити мудака нафіг – вам потрібно певні об’єктивні налаштування вашого погляду на цю ситуацію. Розгляньмо кілька аспектів цієї проблеми.
Читати даліAn Elegant Puzzle: Systems of Engineering Management
А ось вам не дуже популярна (бо доволі нова) книга від досвідченого менеджера Will Larson про керування програмними проектами – An Elegant Puzzle: Systems of Engineering Management

Книга варта уваги – вона надасть багато цікавих емпіричних та практичних моделей з оцінки різних аспектів ПЗ, надасть щільний досвід менеджменту, організації інженерних команд, купа цікавих практичних проблем та їх розв’язання.
Докладніше на сайтах або подивитись у бібліотеці Антона Вітязя:
Як пасти котів
На мою думку – це одна з найважливіших книг для інженера який переходить до ланки менеджера – людини яка має керувати іншими інженерами. Ха-ха та ще раз ха. Керувати не працює. Бо це котики. Тому правильне питання – як пасти котів. І ось вам відповідь.
Захисники тварин, не переймайтеся! Ця книжка не про жорстоке поводження з тваринами — жоден пухнастик не постраждає. Вона про тих, хто, як і коти, позбавлені стадного інстинкту, — програмістів, і те, як навчитися ними керувати задля досягнення найамбітніших цілей в IT-індрустрії. Книжка буде корисною для менеджерів різних ланок і самих програмістів.

Захоплення

Робота має приносити задоволення у багатьох аспектах – але головним є ваше захоплення роботою. Як завжди є певні нюанси.
Захоплення створювати програмне забезпечення – це захоплення створювати класи, налаштовувати бази даних, розробляти ефективні алгоритми, розмірковувати над розв’язанням задач у термінах функціонального програмування або ООП, готувати дизайн-архітектури або круті тестові сценарії. Це захоплення тим що ми робимо кожний день коли є частиною команди яка створює програмне забезпечення.
Читати даліБА як кінь

Класична відповідь на співбесідах з більшості бізнес-аналітиков щодо роботи – я пишу вимоги. Звідти все про що розповідає БА це функціональні та іноді нефункціональні вимоги, діаграми процесів, схеми даних. Вам потрібен аналітик саме для цього? Все ж гарно?
Якщо вам потрібен БА який пише диктант вимог, писар при його величні продакт-овнер та дивиться метр-вправо, метр-вліво то ок – такий собі кінь із шорами який професійно працює на рівні функціональних вимог. Звісно це жорсткий перегиб і сам тут БА починають лютувати, бити себе копитом у груді та розказувати скільки всього вони роблять, і що без них все це наібнеться. А того хто їм сказав про коня пошиють в козли, дурні та мудаки. Отже, увагу ми отримали 🙂
Читати даліВислухайте, зрозумійте, створіть обговорення та MVP
Розробник починає говорити певну пропозицію … … а ви вже знаєте – це – лайно.
Це не буде працювати, ви вже знаєте що це погана ідея, вам потрібно вже робити по іншому. Ви в розпачі, або шукаєте кулемет для знищення пакосника, це гальмо прогресу не почув вас під час статусу проекту … Секундочку – ви маєте наміри працювати з розробником чи вважаєте що цьому остолопу не місце навіть на лавці? Якщо так – то просто звільнить цього дурбецела. Або щонайменше терміново зупиніть його не дослухавши – покажіть йому що його думки на варті витрати хвилини вашого часу. Зробіть це приниження яскравим та незабутнім. Ніт? Ааааа … тобто це добрий розробник, він вам потрібен? Тобто вже інша справа!
Читати даліСтукач на ваші добрі наміри: козел чи не козел?
Це було дивно для команди коли розробник з ЄС, розробник з команди яка має співпрацювати після конструктивного мітингу щодо складної інтеграційної задачі, після узгодженого порядку дій та запланованої наступної зустрічі … виявився стукачем. Тобто він пішов до менеджерів і розповів як складно працювати, як вони влазять на їх територію тощо. І попросив, щоб ми перестали влазити не у свої справи, перестали тиснути й проявляти негативний настрій.
Читати даліСкіки-cкіки?
Оптимальна кількість відносин між людьми у софтверних проєктах залежать від специфіки як людини (інтроверт чи екстраверт), відносини між людей, так і обставин завантаження (чи робить він щось складне що вимагає концентрації). Попри те що ці складнощі вимагають універсальної відповіді “it depends” – подивімось на загальні пропорції
- Розробник – взагалі мати менше контактів, 3-4 це достатньо (1 QA, 1 PM, 1-2 розробників для взаємодії. Чому? Тому що будь-який додатковий контакт – це час який розробник витрачає на розмови та відволікається від розробки.
- Лід по компетенціях – від 4 до 6. Тому що в середньому це кілька взаємодій з кожним в середньому 0.5 години в день. Тобто 3-4 години в день на піров це Ок. Якщо ми додамо ще кілька людей – ц буде вимагати більше часу та знання більшої кількості проєктів
- Лід групи – вимагає від 0.5 до 1 години на людину в середньому в тиждень. Комфортне навантаження – десь 3 години в день. Тобто це десь 15-30 фахівців на ліда групи. Залежно від складності людей, досвіду роботи з ними – пропорції витрат часу можуть суттєво змінюватись. Так для більше автономних фахівців достатньо 0,5 години на 2 тижні.
Проблема справедливості та актуальності рейтів
Доволі складне питання для менеджера – найм нового співробітника за умов скаженого росту зарплат це проблема дисбалансу зарплат розробників які працюють у компанії вже давно. Цю проблему розумієте не тільки ви, а й ваші розробники.
Читати даліПохвала
Якщо чесно, то нам програмістам дуже потрібна похвала – ми чекаємо на визнання нашої креативної, інтелектуально насиченої та важкої праці на рівні нашого мозку. Щонайменше ми потребуємо вдячності, ми згодні отримувати непублічні порції критики, але нам дуже важлива публічна похвала. За що нас хвалити?
Читати даліРадість розробника ?
- ❤️ Радість створення – ми створюємо, воно працює. Звісно тут десь є магія і навіть творець не зовсім розуміє як воно насправді працює. Але ось воно, кнопочки-контрольчики-API-логи!
- ? Радість пошуку рішень та подолання challenges – ми обожнюємо розв’язувати складні проблеми та робимо відповідно до вимог. Трошечки епічного героїзму та батлів з створеними власноруч орками.
- ? Радість подолання складності – ми розбираємо складні речі по кубикам та збираємо кубики в гнучкі системи. А що до того яки виконати магічні паси CICD або щось таке клацнути на
панелі керування космічною станцієюVisual Studio – і ось з’явилась ПРОГРАМА! - ?Радість абстракцій – ми отримуємо право назвати нове, надати йому атрибути та функції. Ми бачимо як наше маля росте з перших строку коду до самостійного складного класу або навіть бібліотеки.
- ? Радість нових знань – ми постійно вчимося – новим технологіям, мовам програмування, розв’язання типових проблем.
Інженерна небезпека

Серед розробників та навіть серед архітекторів програмного забезпечення є певні притаманні риси які підступні та доволі небезпечні в проекті. Сукупність факторів як от створення складності, надлишкові витрати часу або створення структурних проблем – всі вони внутрішньо сприймаються як добрі наміри. Розуміння наслідків цих добрих намірів можуть допомогти розробникам запобігти негативних ефектів.
Читати даліПідготовка legacy розробника ?
Проводьте співбесіди швидше ?
Проводьте співбесіди швидше, тому що до кінця інтерв’ю вартість розробника може сильно збільшитись.
Про синьйорів та навчання новачків

Якщо у вас буде задача розвитку нових фахівців – розробників – перше що ви сплануєте: обрати синьйорів та кожному дати по 1-2 juniour розробника. Це ж логічно – людина має неабиякий досвід, знання, дуже гарно проводить захист своїх рішень. Здається що гарна ідея дасть швидкий ефект – новачки будуть вчитись у синьйора, синьйор буде витрачати менше часу на прості завдання, собівартість розробки зменшиться. Всі радіють, всі танцюють. Але хєр там. На жаль на практиці це часто не працює.
Читати даліДомовитись з феями
Як пройти швидко співбесіду на позицію Senior Something Developer – діалог має бути коротким:
“Значить так, я знаю що я мідл ну типа мідл … але давайте так – я нікому про це не кажу, ви мені даєте офер. В мене вже є чотири офери, ви останні будете. Ну і так щоб я від вас не пішов через 3-4 місяці та не лівачив дайте мені десь 5500$ на початок або більше … Я же адекват – я з вас 7000$ не питаю”