Про що не дізнається той, хто приєднається пізнішє?
Чи потрібне управління знаннями? — Звичайно, так. Воно підсилює організацію. Але впровадження системи управління знаннями в компанії може стати доволі непростим завданням. Чи варті результати зусиль?
З цією проблемою стикнулася молода українська компанія "Альфа Тім", що працює в галузі інформаційних технологій.
– Я не можу так працювати! — твердо заявив Марк, програміст та один із розробників нового проекту, зайшовши до генерального.
Дмитро, 24-річний директор компанії, на мить навіть розгубився: "Що могло статися, щоб зазвичай спокійний Марк отак вибухнув?" Дивлячись йому в очі, Дмитро перебирав подумки з півдюжини можливих причин.
– Сідай, — нарешті запропонував він, намагаючись бути спокійним. — У чому справа?
Марк впав у запропоноване новесеньке крісло у новому ж офісі, в який вони тільки-но, декілька тижнів тому, перебралися. Під'їхавши до столу Дмитра, він стриманіше, але так само рішуче продовжив.
– Коли все-все вже зроблено — наголошуючи на кожному слові, вимовив Марк, — трапляється, що ще майже стільки ж часу треба буде витратити на всілякі папери. І це при тому, що в мене іншої, моєї роботи — повно. Але не це головне... — Він зупинився, ніби розмірковуючи, чи казати наступну фразу. — Заради чого?! Хіба наші програми стануть гіршими чи кращими від цієї купи документів?! Ми ж обходилися без цього раніше! — Марк зробив паузу, від'їхав трохи назад і додав, як останній аргумент. — Я ж програміст, а не письменник!
...Чи Дмитро знав, що програмісти віддають перевагу "вільному плаванню" і сприймають правила, як обмеження своєї творчості, а папери, як зайвий мотлох? Звичайно, знав, бо і сам був таким нещодавно! Бувало, вперто сидів ночами над програмами, аж поки вони не починали, нарешті, працювати.
Маючи неабиякий як на свої 24 роки досвід, він після річного стажування в "ALTA" — маленькій, але одній з найвідоміших і найдинамічніших скандинавських компаній у галузі створення програмного забезпечення, усе ж був у новій для себе ролі — молодого директора молодої української фірми "Альфа Тім".
"Альфа Тім", зібравши за півроку хорошу команду, створювала програмне забезпечення для українських замовників і виступала головним партнером датської "ALTA" у Східній Європі. За півроку обсяг роботи збільшився настільки, що компанія зросла з двох до сімнадцяти чоловік, переїхала у новий офіс, а стиль роботи змінився з майже сімейного на більш діловий.
Дмитро вважав запровадження удосконаленого процесу створення програм — на зразок розробок відомої NASA та міжнародних стандартів — одним із найбільших досягнень "Альфа Тім"! Процес включав чітке визначення етапів створення програмного продукту та документацію кожного етапу, що мало в підсумку призвести до отримання якіснішого результату. Додатково до цього в роботу над подальшим розвитком програмного продукту могли включатися люди, не залучені до створення його першої версії. "В умовах постійного збільшення обсягів роботи це має сенс, чи не так?" — казав собі Дмитро.
Хто міг подумати, що виникне отака ситуація? Але ось тут сидить зараз Марк, весь збентежений, і "не може так працювати"!
"Альфа Тім"
"Альфа Тім" позиціонує себе на ринку Business-to-Business (її споживачами є інші компанії та організації). ЇЇ фокусом є створення власного програмного забезпечення, консультування у галузі впровадження інформаційних технологій та послуги із запровадження вже існуючих програмних продуктів — як своїх, так і інших розробників. Останнім часом послуги "Альфа Тім" використовуються переважно у виробничих процесах, забезпечуючи перетворення масового виробництва у гнучкіше, зорієнтоване на споживача. Наступним кроком у розвитку компанії стає робота у напрямку інтернет-дизайну та електронної комерції.
Протягом найближчого часу компанія прагнутиме інтегрувати існуючі системи та технології у цих трьох ділянках (системи для забезпечення виробництва; інтернет-дизайн та електронна комерція) і створювати системні рішення на базі поєднання компетенції у цих ділянках.
– Світовий ринок інформаційних технологій потребує зараз дуже широкого спектра послуг, — стверджує Дмитро Шимків, генеральний директор компанії. — І хоча він переповнений компаніями, які пропонують прості рішення для окремо взятих проблем чи потреб, професійний підхід до програмування і створення комплексних рішень можна зустріти дуже рідко. Я думаю, що рівень працівників нашої компанії та знань, якими вони володіють, дозволяє створювати саме комплексні, системні рішення.
Що відбувається на ринку?
Вивчаючи готовність країн до участі в інтернет-економіці, компанія "McConnell International" провела дослідження у 42-х країнах світу, включаючи Україну. Вважається, що саме ці країни є джерелом наступної фази економічного зростання світової економіки, спільно генеруючи три чверті світового валового внутрішнього продукту.
Для оцінки було обрано п'ять факторів:
Інфраструктура: наскільки просте і доступне під'єднання до глобальної мережі?
Державна підтримка: чи є готовність до участі в інтернет-економіці державним пріоритетом?
Безпека інформації: чи можна довіряти тому, як обробляється та зберігається інформація у глобальній мережі?
Наявність спеціалістів: чи є в країні люди, здатні підтримати електронний бізнес та створити економіку, що базується на знаннях?
Клімат для розвитку електронного бізнесу: наскільки легко займатися в країні електронним бізнесом?
За результатами дослідження, єдиним із названих п'яти факторів, стосовно якого Україна опинилася поза межами "червоної", небезпечної ситуації, "що вимагає значного покращення", є наявність спеціалістів. Причому оцінка саме цього фактора порівняно з іншими чотирма виявилася найвищою в усіх країнах Центральної, Східної та Південної Європи, які були досліджені.
Сам же Дмитро Шимків на запитання про те, що передусім впливає на роботу "Альфа Тім" із того, що відбувається на ринку інформаційних технологій України, відповів одразу і однозначно:
– Те, що на ньому майже нічого не відбувається!
"Якщо тобі вдасться — будемо партнерами"
Хоча у 1998 p., коли виникла ідея створення "Альфа Тім", широкі дослідження щодо готовності країн до використання та розвитку інформаційних технологій ще не були доступні (принаймні такі, до яких би була залучена Україна), загальна тенденція "відбувається мало що" була досить помітною.
Тому ідея створення відділення датської "ALТА" в Україні, яка виникла у Дмитра під час стажування в головному офісі "ALTA" в Копенгагені, була сприйнята Тоні Ларсеном, генеральним директором компанії, досить обережно:
– Створювати компанію за таких умов?
Поки ідея все ж таки розвивалася (переважно цим спільно із Дмитром займався Олександр Гац, який на той час був у Києві), Тоні встиг побувати в Україні, щоб, як він каже, "подивитися на все своїми очима".
– Якщо тобі вдасться — будемо партнерами, — нарешті сказав він. "Вдатися" в даному разі означало створення самостійної та успішної української компанії.
Через кілька місяців, у червні 1999 p., з'явилася перша команда, яка невдовзі перетворилася на компанію "Альфа Тім".
Зараз в "Альфа Тім" працює 17 чоловік. Тобто за півроку існування компанії її персонал зріс кількісно більш, ніж у вісім разів.
– Зрозуміло, що далі ми зростатимемо трохи повільніше, — каже Дмитро. — Але, за нашими підрахунками та планами, на 1 січня 2003 р. в "Альфа Тім" буде 64 працівники. Це означатиме для компанії зростання у чотири рази протягом найближчих двох років.
Прийняття рішень і зворотний зв'язок
– У своєму прагненні залучити до прийняття стратегічно важливих рішень абсолютно кожну людину в компанії ми одного разу дійшла до "крайності", — розповідає Олександр Гац, технічний директор "Альфа Тім". — Спробували обговорити майбутню структуру компанії з усіма, хто на той час працював у компанії. І нічого в нас тоді не вийшло. Точніше, вийшов "базар". Цей досвід багато чого нас навчив. На мою думку, існує критична кількість людей, які мають бути залучені до кожної стадії обговорення. Навіть із шістьма присутніми на одній із зустрічей була ситуація, коли ми ніби погодилися з тим, що кожному з нас "все зрозуміло", а коли спробували пояснити, що саме було "зрозуміло", то відповіді збентежили всіх!"
Враховуючи набутий досвід і намагаючись водночас не потрапити в іншу "крайність", приймаючи в компанії усі рішення за всіх, Дмитро та Олександр останнім часом спробували застосувати інший підхід. Приймати рішення щодо конкретних проектів уповноважені їх керівники. А для прийняття рішень, до яких вони вважають бажаним залучити всю компанію, Дмитро або Олександр готують до обговорення структуровану інформацію, варіанти рішень, що розглядаються, та можливих наслідків їх прийняття.
На запитання про те, як здійснюється зворотний зв'язок, яким чином він дізнається про те, що відбувається в компанії, Дмитро відповів, посміхаючись:
– Ходжу і розпитую. Чесно.
І продовжив далі вже серйозніше.
– Поки нас лише сімнадцять, я практично завжди маю можливість хоча б раз на день пройтися по офісу і поговорити майже з кожною людиною.
Знання: звідки час про них думати на високій швидкості?
Досвід Дмитра, отриманий у датській "ALTA", серйозно вплинув на те, як розвивалася українська компанія "Альфа Тім".
Для одного із замовлень, яке виконувала "ALTA", треба було провести тестування та додати нові риси до вже створеного програмного продукту, який забезпечує систему виробництва продукції на підприємстві.
– І тут ми зіткнулися із проблемою. Ми знаємо, як створювати хороші програми, але не знаємо ідеально всіх деталей роботи автомобільного підприємства, яке було клієнтом. (При цьому клієнт пояснює нам завдання так, ніби ми знаємо.) Взявшись до роботи, ми потрапили у складну ситуацію: здогадатися, що саме робить програма, не можемо, а документації майже немає!
– В ALTA цей програмний продукт створювала у 1998 p. маленька команда — 5 чоловік, — коментує Олександр Гац, добре обізнаний із ситуацією. — Кожен з них досконало розбирався в системі, тому документація не була потрібна. Система постачалася замовникам — здебільшого великим виробничим підприємствам. Перші три версії для різних замовників були зроблені швидко. Для деяких замовників до системи додавалися нові риси та можливості. Таких ставало все більше (бо система добре себе зарекомендувала), і команда, яка розробляла базову версію, вже не могла одна виконувати всі замовлення. До цієї роботи стали залучати інших програмістів. Вони додавали певні риси та створювали нові версії, адаптуючи систему до потреб нових замовників. Програмісти, які створювали подальші версії, вже не мали настільки чіткого уявлення про первісний продукт та принципи, закладені в його створення, тим паче його не мали команди, які створювали нові версії, базуючись на вже змінених, порівняно з першим, варіантах. Ті, хто приєдналися пізніше, вже не знали того, що знали ті, хто починав. За таких умов їхні рішення щодо додання нових рис для замовників вже не могли були найбільш оптимальними ані з погляду якості, ані з погляду часу, який на це витрачався.
Чи може система якості стати рішенням?
Прагнення компаній, які працюють у галузі інформаційних технологій, знайти вихід, щоб забезпечити і якість роботи, і можливість для подальшого розвитку своїх продуктів та послуг, зберігаючи творчість у роботі, відбилося у розробці різних варіантів системи якості.
– Це не можна (і я дуже не люблю, коли це роблять) назвати роботою в стилі радянського "ОТК" (ВТК — відділу технічного контролю), — каже Володимир Бекеша з "Альфа Тім", який має багатий досвід впровадження таких систем [ якості. — Це не стільки контроль, скільки інвестиція у те, щоб помилок було менше, і програмний продукт міг потім розвиватися далі. Робота людини, що відповідає за систему якості — це на 60 — 80% забезпечення якості, і тільки на 20-40% — контроль. Основна відмінність — у тому, на якому етапі включається в роботу ця людина. ВТК це робить (чи робив) здебільшого, коли вже отримує готовий продукт, а людина, яка відповідає за систему якості в IT має бути залучена до проекту з першого етапу. Вартість помилки, виправленої на початку, є набагато нижчою, ніж вартість тієї ж помилки, виправленої пізніше. З огляду на ціну нашої помилки це дійсно важливо: хвилина простою автомобільного підприємства — це близько 100 тисяч доларів збитків, і якщо це станеться через помилки у роботі програми — за збитки відповідатиме компанія, яка робила програму.
Перші ідеї щодо запровадження системи якості для "Альфа Тім" передбачали роботу з кожним окремим проектом:
планування;
чітке визначення того, що має бути завершено перед початком кожного наступного етапу проекту;
перевірка якості виконання кожного етапу.
Це доповнюється документацією процесу створення програмного продукту.
Розповідаючи про перші зусилля "Альфа Тім" щодо впровадження власної системи якості, Володимир Бекеша зазначив: — Компанія намагалася запровадити таку систему, щоб для кожного проекту були визначені обов'язкові документи:
чіткі вимоги до кінцевого продукту (відповідно до них відбуватиметься його тестування);
графік виконання проекту: перелік завдань, дати, ресурси та засоби досягнення результатів.
Крім того — і це вже мало визначатися для кожного проекту індивідуально — до вже названих документів могли додаватися:
опис логіки програмного продукту;
опис баз даних (опис даних та взаємозв'язків між ними);
плани, засоби і звіти про тестування продукту.
Хоча перелік документації не виглядає великим, створення цих документів може бути досить об'ємною роботою.
– Опис роботи одного сервера може сягати 15-20 сторінок, так, щоб було дійсно зрозуміло, що він робить, — коментує Микола Полтавцев з "Альфа Тім", — а деякі програмні продукти можуть мати 40-60 таких серверів, що є частинами цілісної системи.
– Українським програмістам важко звикнути до необхідності документувати свої дії, — розповів Олександр Гац, технічний директор компанії. Більшість їх починала працювати ще студентами, виконуючи індивідуальні замовлення, і документація, як правило, не вимагалася (так само, як і подальше вдосконалення продукту).
Якщо ж вдосконалення вимагалося, то це мало шанси стати проблемою, бо нечітко обумовлені і зазвичай ніяк не зафіксовані вимоги могли призвести до необхідності переробляти весь продукт багато разів.
– Запровадження системи забезпечення якості підвищує індивідуальну відповідальність, — зазначає Володимир Бекеша, — але водночас дещо зменшує свободу кожного із працівників, принципово визначаючи межі для творчості, своєрідну канву в роботі. Тому це не могло не викликати спротиву: "Навіщо, коли і так зрозуміло?" та "Ми зробимо програму, не сподобається — переробимо!" — такою була перша реакція програмістів на введення вимог щодо документації.
– Існує небезпека, — висловив свою думку один із програмістів, — що якщо занадто регламентувати роботу (наприклад, встановити фіксований робочий день — від 9 до 18, дати завдання працювати "за такою і такою схемою"), то це перетвориться на ремісництво, і нічого нового не буде створено! Тому цілі і засоби не можна міняти місцями. Стандарти та документи мають допомагати створювати кращий продукт, а не заважати.
"Чи не заведе нас прагнення досконалості до руйнування того, що вже створено?" — думав Дмитро, шукаючи відповідь на запитання Марка. "Чи це дійсно поліпшить нашу роботу?"
Брук Менвіл, директор з організаційного навчання корпорації Saba Software (Каліфорнія) та головний редактор електронного журналу LiNE Zine, присвяченого навчанню в новій економіці.
– Регулювання важливе, якщо компанія хоче бути прибутковою. Але слід віднайти такі форми регулювання, щоб воно заважало найменше.
По-перше, всі творчі (включаючи створення програмних продуктів), якщо вони мають бути прибутковими, повинні розумно поєднуватися з дисципліною документації та стандартів. Достатньо подивитися на приклад будь-якої великої та успішної компанії, яка розробляє програмні продукти: рано чи пізно перед ними поставала та ж проблема.
Найскладніше, на мій погляд, — запровадити дисципліну, "не вбиваючи" інновацію. Із досвіду можу сказати, що коли творчий процес є зрілим та стабільним, впровадження стандартів та документації може навіть допомогти. Якщо ж він "молодий" та інновації — іноді непередбачуваної — багато на кожному етапі, то з запровадженням стандартів краще бути обережним. Занадто поспішне введення регулювання має тоді всі шанси припинити інноваційний розвиток.
Щодо того, яким чином впроваджувати документацію та стандарти, то для мене головне, щоб вони ставали додатком, який не заважає основній роботі. Порівняйте дві ролі:
роль водія, який безкоштовно підвозить подорожнього автостопом — це додаткові зусилля, але він продовжує їхати своїм шляхом,
роль людини, на якій висить важкий якір, що тягне її зовсім не в тому напрямку, в якому вона хоче рухатися.
Якщо відверто, про це набагато легше говорити, ніж впроваджувати. У ситуації Дмитра, щоб знайти модель, яка не зашкодить, прелюдією до розробки та впровадження документації роботи має бути творчий погляд на те:
1) які процеси в роботі програмістів вже добре відлагоджені,
2) яким є їхній стиль роботи та,
3) якою є їхня взаємодія.
Найкращий варіант — вивчивши роботу програмістів, знайти ті процеси, до яких документація може "додатися", не стаючи повністю окремим видом роботи. Найімовірніше, доведеться залучити програміста, який зможе спрямувати цю роботу як один із тих, кому доведеться застосовувати її результати.
Оле Квіст-Соренсен, агент зі змін, власник компанії Global Outpost, випускник університету Kaospitol (Данія) та дослідник університету Роскільде (Данія) у галузі інновації та навчання:
– Відповіддю на зростання складності організації ніколи не буде "продовжувати робити все так само".
"Альфа Тім" переходить із одного етапу розвитку в інший. Спершу, у маленькій команді, кожна людина розуміє, що роблять усі інші. Комунікація відбувається легко — "сама собою". Коли збільшуються розміри організації та кількість її працівників, відповідно зростає потік інформації, знань та завдань.
Зростає складність організації. Відповіддю на це зростання складності ніколи не буде "продовжувати робити все так само".
У ситуації Дмитра проблема навколо документації роботи ілюструє, як разом із змінами (зростанням організації) змінюється і сама робота, і компетенції, необхідні для її виконання. Стає необхідним відображати розвиток і компанії, і її продуктів, щоб переконатися, що знання залишаться не тільки у перших розробників продукту, але й будуть доступними тим, хто продовжуватиме їхню роботу.
Якщо цього не зробити, компанія буде вразливою у кризових ситуаціях та при зростанні швидкості розробки продуктів та виконання завдань.
Рішення у ситуації Дмитра може полягати в тому, щоб розвинути у програмістів нову "звичку" — документувати свою роботу — і, таким чином, розвивати та збільшувати те, що називається "інтелектуальним капіталом" компанії. Один із шляхів (яким би простим він не виглядав) — це просто сказати програмістам, щоб вони припинили жалітися, а документували свою роботу, бо це важливо.
Але я вважаю, що відповіддю на зростання складності організації має бути запровадження у ній нових функцій. Тому рішення, яке я пропоную для вирішення описаної ситуації в "Альфа Тім", — залучити менеджера з управління процесами на термін впровадження нової функції — документації роботи. Цей спеціаліст відображатиме, аналізуватиме та забезпечуватиме внутрішньоорганізаційну комунікацію та документацію. Фактично це означає відображення розвитку організації.
У ситуації Дмитра менеджер з управління процесами буде функціонувати як помічник і Дмитра, і Марка. Марк має знання, але не хоче їх документувати. Менеджер з управління процесами займатиметься документацією знань Марка та інших програмістів, вивільняючи їхні ресурси для концентрації на програмуванні. Працюючи подібним чином і з іншими процесами в організації, менеджер з управління процесами у принципі в змозі відобразити всю картину організації та її розвиток. Цю "картину" також можна назвати відображенням організаційного навчання.
Поки ця робота триватиме, Марк, маючи можливість побачити, яким чином працює менеджер з управління процесами, і вчитиметься, як інтегрувати частину процесу документації у свою роботу.
Внаслідок реалізації такого проекту кожна сторона зрозуміє власну роботу краще і, крім того, краще бачитиме свій внесок у кінцеві результати компанії. Відтак з'являється потенціал створити краще розуміння і повагу до роботи інших людей у компанії. Врешті, це призводить до того, що кожен з працівників виконує свою роботу краще.
Що трапляється, коли питання про ефективне управління знаннями виникає у великій організації чи у коаліції таких організацій? Чи працюють там такі самі підходи, які могли бути застосовані в "Альфа Тім?"
Ендрю Бейнс, колишній керівник проектів у Європейському центрі сталого розвитку SONY в Німеччині, а нині — керівник подібного Центру в Європейській штаб-квартирі Apple у Парижі. Він поділився інформацією про унікальний проект з управління знаннями, з яким йому довелося ознайомитися.
Коли до проекту залучено багато людей, то найбільш ефективним засобом для управління знаннями стає інтернет-технологія.
Оскільки наукова розробка шляхів зменшення промислових викидів небезпечних для людини речовин в атмосферу є справою аж ніяк не дешевою, коаліція із близько 150 міжнародних компаній із 30 країн та понад 20 промислових секторів у 1999 p. розпочала проект "Чистий шлях розвитку". Він передбачав обмін знаннями як цих компаній між собою, так і з іншими організаціями у державному та недержавному секторах щодо технічних та організаційних механізмів зменшення викидів.
Як коментує цей проект Філіп Камерон, консультант із Lloyd Masters Consulting 21 (компанії, яка відповідала за розробку та впровадження проекту), оскільки "саме по собі управління знаннями практично включає в себе збирання даних та їх розповсюдження з метою відтворити навчання", завдання проекту "Чистий шлях розвитку" полягало у створенні системи, яка дозволяє швидко знаходити потрібні знання та отримувати їх у спосіб, дешевший за власну розробку. Складністю було знайти шлях, який не відтворює багато вже існуючих та наповнених сторінок в Інтернеті, а пропонує своїм користувачам додану вартість. "Нам було цікаво закласти в систему не тільки висловлені словами знання, але доступ до невербальних, які залишалися в людських головах. Завдяки усвідомленню цінності невербальних знань і того, що зафіксувати їх є малореалістичною метою, ключовим завданням проекту стало створення середовища для обміну знаннями, заснованого на поєднанні людей між собою".
Різноманітність тих людей, які користуватимуться системою, разом із тим, що сама тема, для якої розроблялася система — зменшення небезпечних викидів — знаходилася все ще у стані бурхливого розвитку, призвели до рішення сфокусувати створення системи управління знаннями у квадраті "невербальні знання/ зв'язати".
Це призвело до пошуку системи програмного забезпечення, яке уможливлює такий зв'язок. Було обрано спільну розробку British Petroleum та Adept Computer Services Limited, яка передбачає просте створення спеціалізованих змістовних персональних сторінок в Інтернеті для кожного з учасників проекту, систему посилань (і прямих, і перехресних між всіма сторінками), ефективне здійснення пошуку у межах всієї системи.
Додатково до цього у систему входять тематичні сторінки зі спеціалізованою інформацією, пов'язані з персональними сторінками через систему посилань.
Часом, коли можна буде напевно відповісти на питання, скільки саме — у грошовому вимірі — принесло створення системи компаніям, які започаткували проект, стане спочатку 2008, а потім 2012 p. — це термін, до якого вони забов'язалися поетапно працювати над зменшенням викидів найбільш небезпечних речовин. Але з погляду підходів до управління знаннями проект вже становить унікальний приклад для вивчення.
Що сталося далі в "Альфа Тім"?
Повернемося тепер до "Альфа Тім" — яким чином все ж була вирішена ситуація в компанії, що сталося насправді?
Напевно, ніхто не знає цієї відповіді краще за самого героя кейсу. Знайомтеся — Дмитро Шимків, генеральний директор "Альфа Тім". Ось як розгорталися події за словами Дмитра та його команди.
– Так буде, — сказав Дмитро, витримавши паузу.
Він нагадав Марку про ситуацію, з якою команда "ALTA", їхніх партнерів, зіткнулася в одному з проектів:
– Ті, хто приєднався пізніше, вже не знали того, що знали ті, хто починав.
Тій команді, що створювала першу версію продукту, теж усе було зрозуміло, і — також, як і в ситуації з Марком, — документувати свою роботу здавалося зайвим клопотом.
Дмитро нагадав Марку і про вартість, яку може мати помилка компанії у готовому програмному продукті:
– Запис чітких вимог до кінцевого продукту допомагає тестувати цей продукт на відповідність визначеним вимогам ще до того, як він потрапить до замовника, — сказав Дмитро. — І ми будемо витрачати час і зусилля на це. Причому — згодом — у кожному проекті.
І пояснив свою позицію:
– Якщо ми хочемо працювати професійно, то маємо вчитися того, як зробити наш продукт придатним і до використання — так, щоб замовник був задоволений, — і до подальшого розвитку.
Усвідомлення того, що і, головне, навіщо, треба документувати, зайняло декілька місяців. Врешті-решт зміни у роботі "Альфа Тім", до яких призвела наявність сформульованих вимог до продукту та документації, відбилися і на тому, як створюються програмні продукти і на стилі роботи компанії.
– За чотири місяці, протягом яких ми намагалися навчитися працювати "професійніше", стало менше геройського сидіння ночами у пошуках помилок та менше переписування програм через не цілком зрозуміле формулювання завдання, — коментує ситуацію один із програмістів "Альфа Тім". — Хоча до паперів все одно важко звикнути!
А Марк (це, до речі, єдина людина, їм я якої було змінене в кейсі) працює в "Альфа Тім" над новим проектом.
Відгук
Ник, nikn@ukr.net Теперь компания закрыта 2007, 0 человек
1. З точки зору спеціаліста "система якості" - це не термін, в рамках загальноприйнятої термінології "система якості" в оригіналі називається Quality Management System, тобто Система Управління Якістю.
2. Програмісти не пишуть документацію на бумазі. Вони пишуть її в коді. :)
3. Відсутня структура кейсу, незрозуміла послідовність викладення фактів, невизначений висновок кейсу.
DoDo, Alexander.Gats@gmail.com Так, після семи років, ми переросли свій "стартапний бізнес" компанія злилася з великою міжнародною корпорацією. Змогла вона цього досягнути тільки завдяки якості своєї роботи. Виходці з нашої компанії, прості девелопери - в нових компаніях зразу отримували посаду не менше "Senior" та "Lead" Developer/Tester або Project Manager.
