Причина непорозуміння між нами і невірного використання технологій. За мотивами статті «П'ять світів» (ПО)


Майже ніколи у всій літературі, присвяченій програмування і розробки програмного забезпечення, не згадується щось важливе, з-за чого ми іноді недопонимаем один одного... Joel Spolsky
Стаття Джоела про П'яти світах (програмного забезпечення) вийшла в 2002 році. За минулі 14 років встигли утворитися нові світи: Мобільні додатки і Хмари, — але сіль статті залишилася незмінною.

Одна і та ж технологія в різних умовах буде давати різну ефективність.

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

Уявіть,
Ми на Землі, наш друг Марк на Марсі. У нас стоїть одна і та ж мета, виростити у своєму Світі урожай картоплі. Технологію будемо використовувати однакову «посадка у грунт», а результати отримаємо різні так як вплив факторів/змінних різне для кожного з Світів.
Це здається очевидним, але факти з життя говорять про зворотне.Це Марк

Факти ігнорування контексту
Факт №1 про Консультантів
Кожен рік ми проходили аудит зрілості процесів розробки моделі CMMI і від хлопців консультантів не раз доводилося слухати, що у нас «зайве» і що нам «потрібно» зробити, щоб було краще. При цьому хлопці спираються не на контекст, а на список практик, який може бути взагалі використаний для підвищення «потужності» процесів розробки.
Хлопці, у вас довгий цикл випуску релізу, одна з причин — ви пишіть ТЗ до початку розробки. Оформляйте документацію на систему або в процесі, або після закінчення робіт, цим ви зекономите термін випуску релізу на два тижні.
Виглядає як слушну пропозицію. Тепер накладемо контекст.

Корпоративна ІС перетравлює операції на 60 млрд. рублів в рік, в день через неї проходить 170 млн. рублів. В системі працює понад 2000 чоловік. Схожий на наш бізнес — Московська Біржа і підтримувані нею торговельні операції.
Особливість нашої КІС в тому, що вона монолітна. Якщо оновлюється один з функціональних блоків всередині, помилки в ньому здатні вивести з ладу всю систему або робочий процес. Для компанії це означає фінансові втрати і наступні перевантаження в роботі компанії, так як пропущену роботу на 170 млн. рублів потрібно зробити і нагнати «простий».
На фондовому, валютному і терміновому ринках Московської біржі нештатна ситуація… Останній раз біржа зупиняла торги 1 вересня, але це торкнулося тільки секції «Основний ринок». Цей збій став четвертим за останні чотири місяці.Lenta.ru
Тепер контекст дає можливість зіставити що краще
  • виграти 2 тижні з 3-х місячного циклу випуску релізу, але значно збільшити ризики простою,
або
  • поки залишити ТЗ в тому місці, де воно є, мінімізувати ризики, і шукати інші варіанти скорочення тривалості релізної циклу.
У нашому випадку В роботі паралельно знаходилися 3 релізу і новий виходив кожен місяць. Для нас питання стояло не в тому, щоб скоротити релізний цикл, а чи варто далі нарощувати частоту випуску релізів: випускати не раз в місяць, а раз на два тижні.
І в концептуальному плані починати рухатися до витаскуванню з КІС кожного функціонального блоку в самостійний додаток, зробивши КІС платформою для них. Це дозволить робити одночасно хоч 10 релізів за кількістю додатків.<habracut/>
Це Марс

Факт №2 про Керівництво
Іноді доводиться чути від нових високих керівників такий посил:
Хлопці, у мене на колишньому місці процеси були влаштовані ось так, проблем не було, тому ми будемо переходити на них.
Там це не Тут… Не поспішайте виступати капітаном очевидністю і намагатися відкрити йому очі на це. Моя особиста статистика показує, що вас розцінять як відмовляється співпрацювати і запишуть в «чужі», в системі координат «свій | чужий».
Дочекайтеся від керівника конкретних дій і вже їх зіштовхує з реальністю.
За 6 років роботи в компанії Керівник Проектного Офісу змінювався тричі, один раз разом з усією командою Офісу.

Мене засмучують спроби без розбору натягнути всі проекти по створенню, впровадженню та розвитку на відповідність вимогам PMBoK або стали модними Scrum або Kanban.
Є заточені під ІТ-проекти методології, які діляться на методології створення, упровадження і розвитку.
  • SureStep і ASAP для проектів впровадження корпоративного ПЗ.
  • RUP і MSF як методології створення великих ІТ-рішень.
  • Agile:Scrum як методологія створення «малих» форм і розвитку існуючих.
І кожен зі Світів ПО вносить до них свої корективи.

Вихід: Використовувати бажання і енергію керівника на реалізацію поліпшень, почавши з тих ділянок, де вони потрібні і/або там, де він хоче дасть позитивний ефект.<habracut/>
Марк садить картоплю

Факт №3 про Хабравчан
Проскакує це і в обговореннях на хабре. З недавнього «Про рабів, героїв і рабів-героїв»
Побачив в вашій класифікації «бидло», і далі читати не став. Якщо у вашому аналізі людей є таке поняття, це означає, що у вас ще недостатньо розуміння людей і світу, щоб робити якісь висновки.
Людина статтю не дочитав і в контексті застосування терміна» не розбирався, але визначив, що Автору бракує розуміння людей і світу.
Слідом йде змістовний коментар від іншого Читача:
Автор, схоже, невдало вибрав термін. Я теж не відразу зрозумів цього терміна, занадто специфічні значення в нього вкладають, в тому числі образливі.
З іншого боку підібрати більш точне слово має значення «люди, що виконують важку роботу і займають низьке соціальне становище, духовно нерозвинені, безсловесно покірні люди, які підкоряються чужій волі і дозволяють себе експлуатувати» може бути важко.
Це Марс Дитинко = фак ап

Спосіб визначити, що контекст не враховано і відновити його
Вірний спосіб визначити, що контекст не враховано, Автор статті в явному вигляді не вказав його, але при цьому здається:
  • що в описаному рішенні багато зайвого;
  • що знаєш спосіб як зробити краще.
Воно може і так, але точно не варто поспішати з тим, щоб заявити його правильним, що він краще.
Можна нарватися на те, що співтовариство в жорсткій формі вкаже що ми тут обговорюємо «м'яке», а ви про «гаряче».

Починати варто з протверезіння себе і задавати собі 4-х питань:Протверезіння від захоплення думками, що виникли з вникання в технічні деталі і нюанси.
  1. З якого Світу ЗА знання і досвід, викладені в статті?
  2. Навіщо і чому Автор зробив саме так?
  3. Які альтернативи розглядав Автор, між ніж вибирав?
  4. Які вхідні параметри у вирішеною автором завдання?
Можливо, не на все вдасться відповісти самому і знадобиться допомога Автора у відповіді на них. Задати уточнюючі питання Автору ви також допоможете йому краще зрозуміти що він Створив.
І вже після цього, поринувши в контекст, приміряти свої варіанти до завдання і виготовленим рішень.

Всім гарного «врожаю картоплі» у вашому Світі і змістовних обговорень в коментарях.



Стаття Джоела російською
Стаття Джоела англійською
Хто такий Джоел Спольски? — стаття Wiki русском і англійській.
Ілюстрації з фільму Марсіанин.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.