Архіви категорій: Ролі в IT

Скільки беклогів у вашому проекті?

В реальності може існувати декілька видів беклогу – паралельно жити своїм життям:

  • Беклог власника продукту – з чим прийшов до команди як замовник, на підставі чого планує product roadmap.
  • Беклог команди – що команда пропрацювала та що використовує при оперативному керування.
  • Беклог сподівань та очевидних речей – беклог замовника, я це не пишу, бо це і так очевидно (надалі перелік який змінюється час від часу)
  • Приватний таск-ліст розробника – окрема табличка з тасками яка може перетворитись в … Таємний беклог розробника – там з’являється технічний борг, ідеї щодо того що він хоче покращити або чим погратись з боку технологій. Кількість таких власних беклогів залежить від вподобань розробників та їх власного та незалежного бачення як правильно.
  • Беклог у коді – примітки щодо недороблених речей, відсутності обробки виключень, технічний борг, потенційні баги.
  • Беклог тестувальника – тест кейси та все що дізнався QA переглядаючи угоду, аналітичні документи, архітектури, всі інші вимоги тощо.

Наявність, кількість, ізольованість та різноманітність наведених вище беклогів у рамках проекту – це фундація конфліктів, низької ефективності, непередбачуваності та високого рівня незадоволеності всіх stakeholders проекту.

Вподобайка для low code / no code

Магічний вплив простих речей на замовника від https://www.facebook.com/Moshkovsky.art/

Рекламне гасло лідерів low-code / no-code: громадянин-бізнесмен може зробити свою програму. Чи це правда? Так. Це те що бажає бізнес? Мабуть, ні. Чому?

Читати далі

Що робить EM?

Чому їжачок Moshkovsky.art такий рішучий ви дізнаєтесь якщо дочитаєте до кінця

Серед ролей у IT є такий диво-коник: Engagement Manager (EM). Основна місія EM: знайте правильне рішення для правильного клієнта.

Давайте відразу визначимо що не є основною задачею – або ким не є EM:

  • EM не Сейл (AM) – бо не шукає правильних клієнтів, будує з ними відносини
  • EM не Адміністратор для підготовки контрактів або не помічних сейла – бо не займається підготовкою пакетів документів, не відстежує роботу тендерних майданчиків
  • EM не Маркетинг – бо не шукає потенційних клієнтів, не розвиває сайт та соціальні мережі, не виконує інформаційні розсилки, не організовує події
  • EM не керівник проектів (PM/DM) – тобто не керує виконанням проектів.
  • EM не бізнес-аналітик – тобто не займається повним виконанням бізнес аналізу, не створює аналітичні документи
  • EM не архітектор

… Але з іншого боку він або дуже пов’язаний у своїй взаємодії з ролями наведеними вище або навіть виконує їх частково. Зацікавлені?

Читати далі

Улюблені фічі

З початком проєкт після першого Project Kick-off починається велика політична гра власних інтересів членів команди щодо фіч рішення. Чи буде це зроблено навмисно? Мабуть, ні. Але чому так станеться? Тому що навіть розробники – люди (чи не всі?).

Читати далі

YAGNI, нафіг

YAGNI — You ain’t gonna need it – вам це не потрібно. Все, що не передбачено технічним завданням проекту, не повинно бути в програмі. Або перестань вигадувати додаткові лісопеди та складнощі, не пиши чого-сь щоб-було тому що якщо-шо.

Читати далі

А якщо …

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

Читати далі

TPM/BPM

Кожна позиція має свої особливості – project manager не є виключенням. На практиці існує купа умов щодо домену, технологій, платформ, конкретного бізнесу, культурного коду та міксу додаткових ролей які має виконувати Project Manager (а тут від бізнес-аналітика до фінансиста). Але головне це визначитись стратегічно: вам потрібен технічний керівник проектів або бізнесовий?

Читати далі

Невизначеність, припущеннями та всім зрозумілі речі

Кожен проект має свій рівень невизначеності, свої припущення та час від часу вимоги які мають бути реалізовані тому що це всім зрозумілі речі. Кожна з цих компонент створює у проекті хаос у межах – кожний раз випробуючи на міцність обсяг роботи, час та витрати проекту. Що ми можемо робити з цим? Керувати!

Читати далі

Оцінка всього беклогу as early as possible

Так, так – у Agile проекті потрібно робити якомога повну оцінку всього беклогу. Так – це буде не точна та не повна оцінка. Але це оцінка!

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

Читати далі

Timeless Laws of Software Development

Завжди круто почути історії досвідченого розробника, переглянути історію проблем та пошук рішень. Книгу “Timeless Laws of Software Developmen” написав досвідчений розробник – Jerry Fitzpatrick.

Читати далі

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

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

Читати далі

Вимоги: шматочками ітераційно VS цілісно та уточнення

ПлюсиМінуси
Шматочки+ Легко для Product Owner
+ Гнучкість
+ Гарно для продуктів з великою кількістю неперевірених продуктів
+ Найбільш швидка реакція на зміни у продукті – вимоги змінюються у рамках ітерації
– Відсутніть повної картини, стресс для команди
– Мінливість архітектури
– Переробки у розробників
– Конфлікти у вимогах
– Втрата контролю над змінами та залежностями
– Невизначеність у тестувальників
– Вимагає від експертів реагувати на часті запитання
Цілісно+ Повна картина для всіх інших ролей
+ Надійна архітектура
+ Менше переробок у всіх інших ролей
+ Гарно для процесів та рішень із зрозумілою мотивацією та стабільністю вимог
+ Економія часу експертів
+ Підвищення автономності команди
– Напруга для Product Onwer
– Висока вартість інвестицій
– Додаткові затрати на оновлення
– Більше часу на підготовку
– Пізніше старт проекту
– Погано коли дуже багато ймовірних гіпотез на старті

Форма вимог: Use Case vs User Story

Use Case – це повна та гарно деталізована форма вимог. User Story – це антистресова компромісна форма вимог для спрощеного підключення вимог у Agile проєкті. За умов гарного пропрацювання куца форма User Story плавно перетворюється у Use Case.

Що таке UAT

Для команд розробки UAT (User Acceptance Testing) не дуже часто є частиною їх практики – він може проходити поза лаштунками первинного виробництва, його можуть проводити якось-такось. А ось коли замовник просить вас підготувати Стратегію тестування та визначити як ви будете проводити та готуватись до UAT – ви починаєте скажено гуглити what is faking UAT. Це нормально. Є кілька точок зору на UAT – пропоную варіант.

Зрозуміймо нащо проводити UAT. Замовник бажає визначитись чи дійсно замовлене програмне забезпечення. А як замовник це визначить? З точки зору замовника програмне забезпечення має забезпечувати роботу основних бізнес-сценаріїв від початку до кінця. Тобто ми маємо визначити всі наскрізні бізнес-сценарії, відокремити всі гілки прийняття рішень та таким чином отримаємо план тестування та виконати весь бізнес сценарій (процес) від початку до кінця.

Читати далі

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

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

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

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

Читати далі

Багофікусники на проді

Оце так дивний лук від Moshkovsky_art

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

PS Якщо ви таке робите або ваш колега – то це гарна нагода подарувати йому кружку.

Прості речі

Успішна розробка залежить від багатьох факторів. Є кілька важливих факторів: перше це якість людей. Друге це – планування. Третє – робіть прості речі. При цьому баланс якості та стійкість коду, модульність. І все це в умовах спокою та відповідальності. Все просто 🙂

Читати далі

Обирайте ступінь деталізації вимог та необхідні причандали

Для аналітика у проекті важливо не потрапити у аналітичний параліч. Причина паралічу – непомірна кількість питань кожне з яких аналізується досконало – деталізація, всі типи причандалів (схеми, моделі, прототипи, матриці залежностей). Як врятувати себе від паралічу? Правило 20-80 можна застосувати до вимог – 20% вимог мають мати високий рівень деталізації. Це може вам суттєво допомогти в оптимізації своєї роботи.

Читати далі