То така хуйня трапляється майже з кожним розробником. Але що робити щоб такого не було? Ну взагалі то так … Аде ж крім того, щоб було взагалі все класно – це ще налаштувати базовий CICD. І це на якась там фігня або цацки девопсів – це загальна культура для інженерів та … менеджерів.
PS Якщо ви таке робите або ваш колега – то це гарна нагода подарувати йому кружку.
Трушно від Moshkovsky_art.
А що робити, щоб така фігня не сталась? Успішна розробка залежить від багатьох факторів. Є кілька важливих факторів: перше це якість людей. Друге це – планування. Третє – робіть прості речі. При цьому баланс якості та стійкість коду, модульність. І все це в умовах спокою та відповідальності. Все просто – а докладно тут.
Успішна розробка залежить від багатьох факторів. Є кілька важливих факторів: перше це якість людей. Друге це – планування. Третє – робіть прості речі. При цьому баланс якості та стійкість коду, модульність. І все це в умовах спокою та відповідальності. Все просто 🙂
Читати далі
Керівники-початківці мають доволі типовий набір гріхів менеджера. Вони проявляються через нашу дуже схожу сутність людини і мають коріння у природі людини. Гріхи потрібно роздивитись та визнати, зрозуміти їх природу та шлях до виправлення. Це нормально мати гріхи, ненормально їх ігнорувати та виправдовувати.
Читати даліВивчаючі технології ми дуже швидко набуваємо дуже поганої властивості – технологічного снобізму. Тобто як так – вони цього не розуміють, які тупі! Це ж так просто! Це не круто, це гівнясто. Давайте поясню чому.
Читати далі
Ви як керівник маєте знати стан presales/engagement – тобто тощо що з певною вірогідністю стане фактичними проектами у зоні вашій відповідальності через місяць-два. Знання нових проектів – це знання нефункціональних вимог та цільових архітектур – все що визначає технічний skill set, це розуміння кількості та якості інженерного складу команди який ви маєте сформувати на момент запуску проекту.
Нагадайте мені – коли так було що для нового проекту є все що необхідно? О так, не вистачає людей, не вистачає досвіду, не вистачає знань технологій. Цей бідосік це є ваш факін джоб. А що робити коли ви знаєте стан срака-є (ass-is), голос з світлого майбутнього (вимоги до ресурсів to-be)? Так ось у вас є купа варіантів!
Читати далі
Для аналітика у проекті важливо не потрапити у аналітичний параліч. Причина паралічу – непомірна кількість питань кожне з яких аналізується досконало – деталізація, всі типи причандалів (схеми, моделі, прототипи, матриці залежностей). Як врятувати себе від паралічу? Правило 20-80 можна застосувати до вимог – 20% вимог мають мати високий рівень деталізації. Це може вам суттєво допомогти в оптимізації своєї роботи.
Читати даліЯкщо коротко – ні.
Менеджер повинен мислити на декілька кроків вперед (от сюрприз бляха). Особливо коли це стосується завантаження інженера. Якщо на цьому тижні в проекті завантаження не більше 70% – чи потрібно терміново шукати додаткові задачі або навіть part-time завантаження у інших проектах? Не завжди. І ось декілька причин для цього.
Читати далі
Застосування сучасних ALM рішень (таких як Microsoft Azure DevOps або Jira) надає чудові інструменти для планування та оперативного відстеження стану проекту та відповіді на головні питання. А серед них питання скільки нам потрібно часу для виконання окремих задач, історій користувачів (Use Story) та проекту в цілому – є питанням #1. За умов застосування Agile ми маємо два виміри для цього – Story Points для User Story та години для Tasks.
Читати далі
Доволі часто клієнти бажають отримати для своїх задач найякісніших фахівців. Іноді що оптимізувати ціну питання. А ще додати таких фахівців зараз. Ну ідеальна модель – хочу все круто, дешево та вчора або зараз. На заїбись, як кажуть, а де так можливо? А у нас як завжди …
Читати даліНавчання має бути за крок до challenge. Давайте новачкам можливість зрозуміти технологію, потім допоможіть опанувати певні прості задачі. Після того як вони зрозуміли що це та навіщо це – дайте більше матеріалів для навчання та самостійної практики. Навчання йде краще якщо разом з цим ви надаєте картинку “challenge” – майбутніх задач завтра.
Читати далі
Розробнику, ліду та менеджеру постійно потрібно шукати баланс між корисністю та досконалістю програмних рішень.
Читати даліДуже прикро бачити поважних Senior Developer-ів які ігнорують молодших за рівнем знань колег. Що зробило цих талановитих інженерів ізольованими та як можна це змінити?
Читати далі“In order to enable change, companies have to learn that keeping managers busy is a blunder. If you have busy managers working under you, they are an indictment of your vision and your capacity to transform that vision into reality. Cut them some slack.” – Tom Demarco
Читати даліНайбільший гріх керівника розробників – втрати часу людей. Або незграбне витрачання їхнього часу.
Майже цитата з Peopleware, Tom DeMarco & Timothy Lister
Ви робили це 5-10-15-20-… років тому? Почуваєте необхідність писати код? Code!
Це корисно з декількох причин:
Вміння круто писати код без жодного досвіду роботи з людьми та відсутністю soft skils АБО вміння круто керувати іншими людьми, досвід вирішення бізнес питань без знання деталей розробки ПЗ – все це не означає що ви зможете керувати розробниками. В обох випадках більше ймовірність для провалу.
Істина десь посередині – якось вмієте писати код та розумієте процес, рука тягнеться до поліпшення організації, але ще не дуже розумієте що робити з soft skills. Ви бачите як ви імпульсивно тягнетесь до комунікацій, до людей, але все ще працюєте з софтом. У такому випадку шанс стати добрим керівником для програмістів значно кращий.
Чи має керівник програмістів який ставить оперативні задачі вміти розробляти код? Це дуже політичне питання, існують полярні думки та варіанти та можна витрати купу часу на it depends. Надалі не буде цього, буде проста окрема думка.
Наразі швидка відповідь – дуже бажано вміти писати код або власноруч створювати програмне забезпечення.
Читати далі