З широко закритими вихідним кодом, Комерція, Різне, статті

У світі сьогодні сформувалися два радикально протилежних методу організації софт-проектів: “соборний”,* властивий приватним компаніям і виробляє преімущственно закритий пропріетарний** код, і “базарний”, спонтанно виник в співтоваристві OSS*** і виробляє відкритий і найчастіше безкоштовний код. І нехай жоден з цих методів не може похвалитися своєю перевагою в сенсі якості та ефективності розробок, проте обидва вижили до сих пір, і отже довели своє право на існування. Візьмемо ж, хлопці, цей факт на замітку …



Рик Кіттс у своїй вельми емоційною репліці на artima.com зізнався, що він постійно розмірковує над проблемою якості коду ось уже 10 років. “I constantly think about this “, пише він. І хоч він бачить проблему лише в одному зі світів, пропрієтарного (і валить всю провину на босів – про це трохи пізніше), як нам здається, ця проблема все ж виходить за рамки бізнес моделей і притаманна як “собору”, так і “базару”.


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


* “Соборний” і “базарний” методи – натяк на знамените есе Еріка Реймонда “The Cathedral and the Bazaar


** Пропріетарний – нове слівце в російській мові, яке вже встигло просочитися в словники; від proprietary, тобто власницький. Пропріетарний код – це коли все що ви пишете в компанії, навіть i = 0, є її власністю.


*** OSS (Open Source Software) – ПЗ з відкритим вихідним кодом. Явище, яке зараз виробляє напевно більше шуму, ніж на початку минулого століття – комунізм. У OSS є свої лідери, “Маніфест”, і стимул щось робити на благо людства, але вже ніяк не заради грошей.


Ферма і прерії


Втім, всякий оптиміст відзначить, що хороший код існує в обох світах (якщо цей оптиміст – неупереджений оптиміст), і приведе деякі приклади. Окей, це дуже добре, що він, хороший код, існує, тому що цей чудовий факт дасть нам шанс зрозуміти, як слід організовувати софт компанії або спільноти, які виробляли б нехай відкритий, нехай “широко закритий”, але хороший код.


Якщо не думати занадто довго, то відразу можна дати таку очевидну відповідь: хороші системи створюють хороші програмісти, або великі хакери (по Полу Грему). Добре, ви придбали такого хакера, але ви можете забути про те, що ВХ, як будь-яка творча особистість, річ примхлива: з одного боку він “в неволі не розмножується”, тобто ви можете просто вбити такого програміста у своїй жорсткої корпоративної системи, причому незалежно від посади, яку він буде займати, або, з іншого боку, у світі OSS наш ВХ може швидко втратити інтерес через відсутність грошової компенсації. Ні, ні, зовсім не тому, що ВХ любить гроші, і навіть навпаки, він їх зневажає, ну або байдужий, але вже не настільки молодий, щоб писати код заради самоствердження (адже саме заради цього в кінцевому підсумку створюється велика частина OSS, чи не так?).


Безумовно, великим хакерам потрібно щось інше. Ймовірність того, що ВХ випадково наткнеться на гранично проникливого боса, яким може бути тільки ще один хакер, вкрай мала. І з іншого боку, ВХ настільки зріла людина, що внутрішні мотиви написання безкоштовного софта вже вичерпані. Цей чудовий мозок залишається за бортом.


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


Втім, хлопці, з роками я розумію, що розумію все менше. Як це не дивно, але ще 10 років тому я був абсолютно впевнений в тому, що знаю як треба писати програми. І я їх писав, і був собою дуже задоволений. Але сьогодні … Ох, я був готовий розцілувати монітор, коли натрапив на замітку Джоела Спольски, В якій говорилося про те ж саме, і тими ж самими словами. Джоел, правда, резюмує, що це є ознака дозрівання в вас справжнього програміста, але в цьому я не погоджуся. Зрілість є усвідомлення своїх нездатність, на відміну від молодості, яка впевнена у своїх здібностях. А раз так, то я не беруся створювати великі системи (а головна проблема саме в них): не хочу робити погані системи, і не знаю як робити хороші. Правда швидше за все ніхто цього сьогодні не знає, хоч і всі про це думають. Словом, треба боятися великих систем, хлопці …


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


Кафедральний базар


Окей, як кажуть зажравшиеся капіталісти в старих радянських фільмах, ближче до справи. Те, що буде описано нижче, можливо, хоча зовсім необов’язково, є моделлю хорошої софт компанії. А може навіть і взагалі, гарної інженерної компанії майбутнього. I constantly think about this, правда не 10 років, а щось близько року. Теж чимало.


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


У такій ідеальної компанії майбутнього потрібна певна кількість “великих хакерів”, які будуть на своєму місці, потрібні елементи спільноти та отстутствие ієрархії (або дуже слабка дворівнева система) як в OSS, і потрібна атмосфера творчості, як при зйомках фільму.


Утопія? Не поспішайте з висновками, і замість цього давайте-но спробуємо продумати деталі і доведемо нашу утопію до логічно завершеного стану. І умовно назвемо нашу компанію “Кафедральний базар (КБ) імені собаки Павлова “. Просто так, заради приколу.


Size is the king


У нашій з вами індустрії проізводаства ПО існує такий парадокс: проект, який за традицією повинні робити (і роблять) рота програмістів з 50 осіб, можуть також зробити і 5 чоловік, причому за приблизно ті ж терміни. В одному випадку є гроші, є керівник проекту, який тільки лише вміє розписувати вимоги по 50 позиціям, забивати їх за допомогою стандартного інтерв’ювання, а потім керувати проектом за допомогою UML і PowerPoint. Це все, що він вміє, хоч і треба віддати йому належне, він робить це добре. (Якщо не рахувати того, що ні його методи інтерв’ювання, ні його глибокі пізнання в UML на нашому з вами кораблі вже не потрібні).


В іншому ж випадку є від 1 до 3 великих хакерів, або програмістів класу “А” або “Б” (генії і таланти, відповідно), є тестировщик (и), і є складальник пакета. Дизайнерів, спеців по GUI та інші специфічні професії додавати за смаком. Вся система цілком мається на голові одного або декількох ВХ, який бачить, як треба розбити систему на досить незалежні шматки, наскільки можна формалізувати ті чи інші шматки, щоб згодом легше було модифіковані надбудови і навіть використовувати ці самі формалізовані шматки в інших проектах (reuse, що називається). Ніякої типовий керівник не зрівняється з нашим (і) ВХ в баченні системи, з тієї простої причини, що керівник не займається кодуванням, а ВХ все робить сам, від проектування до реалізації.


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


Знаю, зробити замовника щасливим зможе швидше наш майор, ніж ВХ. Є така проблема: замовник повертає проект з довжелезним списком додаткових вимог. Це найнеприємніша частина. Але скажу вам наступне: при здачі проекту ВХ повинен злегка зменшити свої амбіції і слідувати такому правилу: можна реалізувати 50% з вимог замовника (причому зробити це навіть краще, ніж очікує сам замовник) , А інші 50% відхилити і показати що вони не потрібні або вже реалізовані в тому чи іншому вигляді. Це цілком реально, якщо зробити з розумом. (“Замовник не завжди правий”, як сказав керівник однієї з найбільших в США мереж магазинів, Best Buy).


Отже, розмір компанії має значення. Зрозуміло, я не маю на увазі, що компанія повинна складатися з 5 чоловік, хоча на практиці буває й таке, особливо в ігровій індустрії. Ви можете мати певне кількість крихітних взводів, як описано вище, але загальний розмір компанії все-таки теж має свою межу з огляду на те, що ми в кінцевому підсумку створюємо комуну, або співтовариство програмістів, а таке співтовариство не може складатися з 20,000 чоловік. Якщо ж наш КБ виявився таким щасливим в бізнесі, що почав розростатися як Аліса з’їла відповідний гриб, то слід почати розбивати компанію на більш дрібні, скажемо по 50-70 чоловік максимум, так само, як ви розбиваєте великий софт-проект на більш дрібні, незалежні шматки.


При цьому всі під-компанії залишаються під дахом одного холдингу. Є тільки одна важлива умова, при якому такий холдинг буде дієвий: його власником або співвласником повинен бути великий хакер, оскільки потрібен як мінімум один програміст (а краще – 2-3), який бачить всю картину цілком. Людина, яка бачить всі активні проекти аж до деталей, і який кодує сам – тільки в цьому випадку буде можливо утримати всю цю карусель під-компаній. І це теж реально. Я б сумнівався, якби не бачив такого в реальному житті.


Кодують всі!


В “Кафедральному базарі” повинні кодувати все. Майте терпіння, і ви зрозумієте чому.


Бухгалтер повинен бути таким бухгалтером, який сам програмує свою фінансову систему в Excel, на відміну від типового ледачого бухгалтера, який вимагає від керівництва закупівлі якогось фінансового пакета, а потім постійно скаржиться на погане супровід. Кодувати повинен і VP по маркетингу: він сам організовує якісь дослідження і робить програмки для обробки даних. Багато чого для цього не потрібно, просто хороші, розумні бухгалтери і специ з маркетингу. Уявляю, як до вас прийде кандидат на VPM, ви йому скажете: “у нас таке правило: кодують все, і ви теж будете цим займатися”, він зробить міну, або навіть усміхнеться, типу “ще чого” … ось тоді женіть цього кандидата в шию. Запевняю вас, він вам не потрібен.


Кодувати повинен і директор компанії. І не в своєму директорському кабінеті, а там, де це роблять усе: або в загальному залі, якщо ви так влаштували свій КБ, або в окремому кабінеті спеціально для кодування, якщо у вас всі сидять в окремих кімнатах. Але ніяк не в директорському кабінеті, який залиште для, так би мовити, відвідувачів музею. Звичайно директор не може завантажувати себе в тій же мірі, що і решта програмісти, але запросто може хоча б на 50%. Нехай же він візьме на себе якісь завдання і кодує.


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


Відділ (и) по маркетингу і продажам зазвичай теж відчужені: люди, які знають ринок, і отже вирішують що імеено треба створювати для цього ринку, як правило вважають себе “білими” людьми у порівнянні з програмістами, що займаються “чорною” роботою. Я ще не зустрічав такого спеца по маркетингу та / або продажу, яка не дивилася б на програміста зверхньо. І справа тут зовсім не в амбіціях програмістів і VP, а у відчуженні і всіляких вододілах, які починають виникати в компанії між відділами і людьми з різними родами занять.


Якщо ж ви знайдете для своєї компанії бухгалтера, VP з маркетингу та продажу, і нарешті директора, які вважають програмування привілеєм, і самі будуть з задоволенням кодувати коли потрібно, то тоді ваша компанія знайде вкрай рідкісне в наш час і цінна якість: взаємна повага всіх співробітників один до одного. Тому, це є необхідна, правда недостатнє, умова створення “Кафедрального базару “: кодують все.


Анархія – мати другого порядку


Чув таку історію. Ще на зорі свого розвитку авіаіндустрія зіткнулася з такою проблемою: шасі літака починають сильно вібрувати і навіть ламатися при посадці. Кріпили шасі як могли, а вони все вібрують і ламаються. Академік Келдиш запропонував розслабити кріплення і зробити їх пружними. І що ж? Вібрація зникла.


Тепер настав час взяти зі світу OSS його головне досягнення: анархію як модель ведення софт-проекту.


Як вже було сказано раніше, у світі софт-індустрії існує два різних підходи реалізації великих проектів: або ви створюєте стандартну ієрархічну схему і потім забиваєте її людьми “по резюме”, або ви запрошуєте декількох великих хакерів знаючи, що вони просто зроблять те що треба. В першому випадку не треба багато думати, треба тільки мати терпіння для перегляду N * 100 резюме та інтерв’ювання N * 10 людей. У другому ж випадку треба, по-перше, самому бути ВХ, і по-друге мати хороші зв’язки і знайомства, які виведуть вас на інших ВХ.


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


Що ж повинен робити такий бос для того, щоб ніхто не помітив його некомпетентності? Він повинен створити непробивну стіну між собою і програмістами, і кращої стіною можуть стати … правильно, більш дрібні начальники. А як там в самих низах ієрархії, на рівні M-1, начальники будуть жити із кодувальника – це в верхах вже нікого не цікавить. Хоча і для цього є стандартні засоби: PowerPoint, UML, а для зворотного зв’язку – звіти, звіти …


Це нікуди не годиться. Програмістам класів “А” і “Б” менше всього на світі потрібні начальники. А більше всього на світі їм потрібно відчуття команди та атмосфера творчого творення – ось що їм потрібно.


Але якщо немає начальників, хто ж буде приймати архітектурні рішення в КБ – запитаєте ви? Окей, щас зробимо.


#if !defined(HIERARCHY)
#define ANARCHY


Згадаймо, що кожна компанія в нашому холдингу має невеликі розміри. Компанія умовно розбита на невеликі групи по 4-5 чоловік, кожна з яких робить окремий великий проект, або незалежну частину гігантського проекту – не важливо. По-перше, групи ці не мають начальників: кожна з них керується тими ж принципами, що й аналогічні групи в світі OSS. Людей об’єднує любов до програмування і азарт отримання результату, а дрібні рішення приймаються або колективно, або на основі авторитету ВХ, якого повинна мати кожна група як мінімум в одному екземплярі. Помітили, що така атмосфера виключає необхідність в начальнику і в супутніх атрибутах (як-то: PowerPoint і звіти)?


По-друге, треба якось вирішити проблему великих питань архітектурного плану. Для цього ви на самому початку збираєте всіх співробітників (не забудьте і бухгалтера) і оголошуєте про створення Ради Архітекторів, в який входять всі. Ви говорите, що СА буде збиратися на обговорення архітектурних питань регулярно, скажімо раз на тиждень, і також нерегулярно, в міру потреби.


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


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


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


#endif


У мене, хлопці, є якась незрозуміла впевненість в тому, що це має спрацювати, і більше того, що це найкращий спосіб організації софт-компанії. Давайте-ка не відвертайтеся і не відмовляйтеся, а прикиньте, намалюйте цю картину у себе в голові. Поставте себе на місце програміста, великого хакера, бухгалтера, VP по маркетингу / продажу, і нарешті – директора.


Стоп! Директор – це чи не найважливіша частина в картині, якщо ви вже встигли здогадатися. Якщо пам’ятаєте, ми порівнювали софт-проект зі зйомками кіно … Так от директор нашого КБ – це режисер, і дуже багато чого, якщо не все, залежить саме від нього. Не те щоб продукція або кількість помилок в ній – зовсім ні. А те, чи вдасться створити атмосферу анархії, в якій все просякнуте духом творчості. Може це не так-то і просто … Але, знаєте, хороші фільми створюють тільки хороші режисери (до речі, зворотне не істинно). Директором нашого КБ повинен бути Бергман, Бунюель чи Бертолуччі, і ми будемо довго і завзято його шукати до тих пір, поки не знайдемо. А інакше гра, звичайно ж, не варта свічок. Зрештою, і в світі кіно продюсери і режисери якось знаходять один одного, і від цього вибору залежить все інше.


***


Приблизно раз в 3 роки я міняю свого роботодавця (хоча з його точки зору це він змінює мене – хе-хе). Ходжу по компаніях, проходжу інтерв’ю, співбесіди, і нарешті в якихось випадках – звучить конкретна цифра, яку я чекав, або навпаки не чекав, і запрошення на роботу.


Зважаючи стажу роботи мені можуть пропонувати місце начальника. Зізнатися, я довгі роки уникав цього, але нещодавно знову зіткнувся з цим обличчям до обличчя. Мене інтерв’ював начальник, і запитував про UML і Java, і ще як би між іншим – про PowerPoint (а який букет, однако!). Все. У мене увірвався терпець, і я сказав цій людині все, що думаю про UML, Java і PowerPoint. Забавно, що Java – це не є інструмент начальника, але ця мова якимось чином вписується у традиційні ієрархічні схеми, за що, як мені здається, справжні програмісти його і не люблять. Ця мова була створена для начальників, а не для програмістів, хоча використовують-то його саме програмери …


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


А поки я просто жахливо незадоволений і трохи злий (в міру, в міру) програміст, який веде свій ідіотський Блокнот.


І оскільки сказане вище – лише одна третя частина, ну або половина задуманого, то …


(Продовження, можливо, буде)


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*