Архіви категорій: Забезпечення

Корисні Issues

Завжди усміхнений менеджер проекту

Серед типів work item у Azure DevOps тип Issue використовується не дуже часто. Нажаль. А це дуже та дуже корисний тип work item. Чи варто вам приділяти більше уваги Issues? Безперечно!

Читати далі

Превентивна релокація як фіча хантерів

Цікава конкуренція за кадри між малими та великими компаніями – коли гіганти калькулюють та оптимізують витрати на реалокацію, кажуть та не роблять, маленькі кажуть та роблять – йди від цих жадібних корпорацій в наш комфортний офіс на Кіпрі!

Це доволі крутий приклад партизанського маркетингу на ринку праці! Тобто сьогодні якщо ти middle або seniour і під час співбесіди нема реалокаційного пакету – це вже не офер, а так, жлобство ?

Отакі часи, отакі зміни реальності ?

Свобода реалізації

За умов відсутності вимог можна зробити наступне – прийняте власне бачення реалізації як основне, повідомити про це замовника і виконати роботу на підставі цього.

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

Системна робота над вимогами та Agile

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

Читати далі

Розуміння в цілому

Проєкт потрібно починати з розуміння в цілому – що ми робимо, нащо ми це робимо, де та як воно буде використовуватись.

” – А! Це ж питання до бізнес-аналітиків – нащо інженерам знати це? Нехай BA ібуцця з бізнесом, не заважайте інженерам! ” – отаке можна почути від пересічного софтбудівника.

Отаке … але ніт.

Читати далі

Гріхи керівника інженерів

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

Читати далі

Наші гріхи: технологічний снобізм

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

Читати далі

Добувати знання та досвід на крок вперед

Ви як керівник маєте знати стан presales/engagement – тобто тощо що з певною вірогідністю стане фактичними проектами у зоні вашій відповідальності через місяць-два. Знання нових проектів – це знання нефункціональних вимог та цільових архітектур – все що визначає технічний skill set, це розуміння кількості та якості інженерного складу команди який ви маєте сформувати на момент запуску проекту.

Нагадайте мені – коли так було що для нового проекту є все що необхідно? О так, не вистачає людей, не вистачає досвіду, не вистачає знань технологій. Цей бідосік це є ваш факін джоб. А що робити коли ви знаєте стан срака-є (ass-is), голос з світлого майбутнього (вимоги до ресурсів to-be)? Так ось у вас є купа варіантів!

Читати далі

Чи потрібно доводити завантаження інженера до 100%?

Якщо коротко – ні.

Менеджер повинен мислити на декілька кроків вперед (от сюрприз бляха). Особливо коли це стосується завантаження інженера. Якщо на цьому тижні в проекті завантаження не більше 70% – чи потрібно терміново шукати додаткові задачі або навіть part-time завантаження у інших проектах? Не завжди. І ось декілька причин для цього.

Читати далі

Всі оцінки важливі

Застосування сучасних ALM рішень (таких як Microsoft Azure DevOps або Jira) надає чудові інструменти для планування та оперативного відстеження стану проекту та відповіді на головні питання. А серед них питання скільки нам потрібно часу для виконання окремих задач, історій користувачів (Use Story) та проекту в цілому – є питанням #1. За умов застосування Agile ми маємо два виміри для цього – Story Points для User Story та години для Tasks.

Читати далі

Як джуна додати до реального проєкту?

Доволі часто клієнти бажають отримати для своїх задач найякісніших фахівців. Іноді що оптимізувати ціну питання. А ще додати таких фахівців зараз. Ну ідеальна модель – хочу все круто, дешево та вчора або зараз. На заїбись, як кажуть, а де так можливо? А у нас як завжди …

Читати далі

Можливість для росту: навчання та challenge

Навчання має бути за крок до challenge. Давайте новачкам можливість зрозуміти технологію, потім допоможіть опанувати певні прості задачі. Після того як вони зрозуміли що це та навіщо це – дайте більше матеріалів для навчання та самостійної практики. Навчання йде краще якщо разом з цим ви надаєте картинку “challenge” – майбутніх задач завтра.

Читати далі

Параліч Senior Developer у knowledge sharing

Дуже прикро бачити поважних Senior Developer-ів які ігнорують молодших за рівнем знань колег. Що зробило цих талановитих інженерів ізольованими та як можна це змінити?

Читати далі

Програмували? Програмуйте!

Ви робили це 5-10-15-20-… років тому? Почуваєте необхідність писати код? Code!

Це корисно з декількох причин:

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

Шанси бути керівником для програмістів

Вміння круто писати код без жодного досвіду роботи з людьми та відсутністю soft skils АБО вміння круто керувати іншими людьми, досвід вирішення бізнес питань без знання деталей розробки ПЗ – все це не означає що ви зможете керувати розробниками. В обох випадках більше ймовірність для провалу.

Істина десь посередині – якось вмієте писати код та розумієте процес, рука тягнеться до поліпшення організації, але ще не дуже розумієте що робити з soft skills. Ви бачите як ви імпульсивно тягнетесь до комунікацій, до людей, але все ще працюєте з софтом. У такому випадку шанс стати добрим керівником для програмістів значно кращий.

Менеджер програмістів та вміння розробляти код

Чи має керівник програмістів який ставить оперативні задачі вміти розробляти код? Це дуже політичне питання, існують полярні думки та варіанти та можна витрати купу часу на it depends. Надалі не буде цього, буде проста окрема думка.

Наразі швидка відповідь – дуже бажано вміти писати код або власноруч створювати програмне забезпечення.

Читати далі

Контроль задач

Питання контролю задач важливо як для розробника, так і для менеджера який постави задачу. Звісно що існує багато дуже простих задач – але навіть вони мають свої проблеми. Розгляньмо типові проблеми. (майже) Всі поради нижче мають застосовувати розробник та менеджер.

Читати далі