Нотатки про американський програмуванні, Комерція, Різне, статті

Пропрацювавши 20 років у російському програмуванні і потрапивши у справах в середу американської програмістської компанії, мені було цікаво, звичайно, подивитися, як тут працюють. І порівняти. Перші пару місяців я радів кожному новому свідченням того, що стосовно програмістської техніки я сильніше. Це могло, звичайно, ставитися тільки до моєї першій команді, але поступово стало виглядати як загальний закон. Я завжди знав, що я непоганий програміст, але щоб настільки … Не кажучи вже про “computer science”. Якщо їм, бідолахам, потрібна була компресія, шифровка, картографія або машгеометрія, вони пленталися до мене, здаватися більшовикам … Здогадуюся, втім, що й тут є класні “технарі” і “теоретики”. Це очевидно із загальних міркувань, знаючи, яка тьма все тут напахана, можна бачити високий клас у багатьох текстах, опублікованих у книгах і т.п. Але тут поки мова піде про “типовому” американському програміста.


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


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


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


Структура управління


Перше, що треба розуміти – це що з працюючих на фірмі лише 20-30% на ній числяться, це employees – службовці. Решта – консультанти, вони службовці інших фірм тут лише тимчасово, їх ніби здали в оренду. Характерна їх висока плинність і повна до них безцеремонність з боку основної фірми. Некомпетентність чи просто відсутність роботи – звільнений. Консультант також не схильний зі мною возитися, якщо я опинився “High maintanance guy”. Це не є трагедією, роботи завжди повно і якщо я побачив найкращу можливість або відчув що без мене їм ніяк, я так само безцеремонно вимагатиму гроші на бочку або піду. Проте люди з робочою візою, даної на проект, без грін-карти, яких фірма знайшла в Індії чи Китаї і “імпортувала”, опиняються в безправному становищі, вони змушені жити із господарем за всяку ціну. Консультант отримує більш високу зарплату, ніж службовець, навіть з вирахуванням того, що забирає фірма. Часто, якщо консультант – “хороший хлопець”, тобто у нього висока самомотивація і очевидно, що його не треба буде поганяти, то йому можуть запропонувати перейти в службовці. Це означає падіння в латці, але зате і майже повну безпеку і суттєві “бенефіти”, 4-х денний тиждень, пенсійний план, відпустка … Фірмі це вигідно і керівництво часто натискає, наказуючи позбавлятися від консультантів. Але кожен розуміє, що використання консультантів дає свободу в управлінні кадрами і підвищує гнучкість.


Вся робота проводиться бригадами. Як і скрізь, вони організовані навколо “завдань”, наприклад, по підсистемах або за проектами, або за етапами в проектному циклі (планування – розробка – тестування – обслуговування. Збут не беремо). Або по потокам управлінських даних. Бригада має лідера, як правило із службовців. Хоча це начальник, або, скоріше, координатор, часто він отримує менше всіх в бригаді. Так само часто він вже і не програміст. Неможливо кодувати, якщо треба відповідати на 40 – 100 (і більше!) E-mail в день. У цю пастку неминуче і швидко потрапляє будь-який “координуючий” людина. Плюс наради, на яких вищий шар менеджерів вирішує, що треба робити.


Звідти лідер приносить у дзьобі свіжі ЦУ, збирає нараду команди і починає планувати. Обговорення досить вільне, хоча домагатися консенсусу не потрібно. Якщо немає нависає крайнього терміну, застосовується пріоритетне планування, тобто кажуть, що це завдання має вищий пріоритет, коли вона стоїть – робимо ось цю та т.д. Іноді кажуть, – ось ти витрачай на це роботу 2:00 в день. Якщо крайній термін є, використовується досить дріб’язкове планування для кожного по днях і навіть годинах, хоча контролю за дотриманням я щось не бачив. Якщо крайній термін горить, всі сидять до упору. Діє принцип перевантаження, тобто все завжди повинні бути зайняті і “не встигати”. Тільки сильний лідер і тільки як виняток може допустити несанкціоновану діяльність. Чому це так? Вища ланка менеджерів володіє грошима, цілком реально, у них є бюджет і вони його витрачають цілком безконтрольно, до пори-до часу, поки їм не звітувати. Коли я працюю, я, неважливо, службовець або консультант, списую свій час на ті чи інші проекти, тобто на чийсь бюджет, вказуючи і “вид діяльності”, на рахунок яких є велика класифікація. ВСЕ час має бути кудись списано … Той менеджер, чий це проект, повинен підписатися за мої витрати. Може і не підписатися і краще до цього не доводити. Де залучені гроші, помилки не допускаються. Дисципліна, дедікейшн, мотівейшн … Страшнувато?


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


Хочу зазначити, що вищий шар менеджерів технічно вже давно “clueless”, без поняття, вони це усвідомлюють і ніхто не бачить в цьому недоліку. Їх сила (або відсутність такої) у зв’язку із замовниками, від яких приходять гроші, і в баченні майбутнього (чим будемо платити людям через два роки?). Середній шар, лідери груп, повинні бути технічно сильні, їм не дають все забути, посилають підучуватися, цим людям належить знати “як” і “почому”, але не “що”. Функції не змішуються, а інакше це швидко призводить до кадрових пересування. Рідко коли технічне рішення нав’язують згори. Якщо по видимості це відбувається, то, значить, рішення було нав’язано замовником. Чи це означає, що начальник дурник. І йому скоро кінець.


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


В цілому, є враження механістично раціональності, холоду. Частково воно згладжується соціальними засобами – гумором, обов’язковістю, підкресленням поваги до чужої думки і т.д. Крім того, гроші теж почасти пом’якшують, зарплати високі і це дозволяє відчути певну “привілейованість”. Система виглядає розумніший людей.


Техніка управління та підтримки розробок


Перше, що треба знати – все по email. Нічого не говориться тільки усно, все підкріплюється поштою. Телефон тільки для оперативної інформації та підтримки, розпорядження по ньому не даються. Значення цього очевидно, вся історія залишається. Поштовий пакет дозволяє багато чого, можна сортувати повідомлення по ящиках, шукати, перенаправляти, розсилати за списками. Можна послати таке повідомлення, що стерти його буде не можна – виглядає як загроза і робиться рідко. Нормальний розробник отримує 10-30 повідомлень в день, менеджери отримують сотні.


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


Друге, що треба знати – це PVCS. Роль цього простенького пакета дуже велика і людей, які його (або чогось еквівалентного) не знають, в Америці немає. Або не буде. PVCS – це Program Version Control System, система управління версіями. Це база даних вихідних текстів (теоретично, будь-яких файлів), розташована на Лановська сервері, звідки можна Взяти текст і куди його можна Покласти. Якщо я просто взяв текст, я отримую його саму недавню копію у вигляді файла, захищеного від змін (цей режим можна змінити вручну локально, тоді виникне плутанина). Але я можу також взяти текст, Замкнувши його, тоді він буде доступний для змін, але ніхто більше замкнути його не може. Змінивши “замкнений” мною текст, я можу покласти його назад, при цьому система запросить коментар, а що я зробив?, І привласнить тексту наступну версію. В будь-який момент можна отримати всю історію змін і будь-яку з попередніх версій. Можна помітити колекцію текстів міткою.


Головне призначення PVCS – уникнути ситуації, коли різні програмісти змінюють різні частини одного і того ж тексту. І пов’язати будь-яка зміна з його автором (що робиться автоматично, шляхом запам’ятовування Лановська позивного автора разом з утворенням нової версії) і з якоюсь причиною (що робиться через коментар). Всі коментарі також автоматично додаються в текст як стандартні Сі-коментарі. У нас PVCS працює в тісному зв’язку з MAKEpom: якщо є проект в мейкере, я можу використовувати його, щоб витягти всі останні версії всіх файлів в проекті і все h-файли, крім того, можна дізнатися, а з яких текстів був скомпільований даний модуль. Щоб згенерувати повний набір текстів для якогось модуля, досить сказати “gen імяМодуля”. Важлива властивість пакета – можна дізнатися, які файли ким замкнені. Якщо мені пора згенерувати версію, дуже корисно знати, над чим ще працюють і хто … В цілому, це відмінний організуючий центр.


Третя важлива риса, пов’язана з божевіллям на тестуванні і використанні bound checker “s та інших засобів перевірки якості коду. Для тих хто не знає: bound checker – це щось на зразок відладчика, який ловить виходи за межі масивів, взяту і неотданную (або навпаки) пам’ять, а також, що важливіше під Windows, системні ресурси, не ті аргументи у викликах системних функцій, копіювання з перекриттям і т.д. На деяких фірмах ОБОВ’ЯЗКОВО мати чистий протокол bchkw при здачі модуля. На нашій не так, все б зупинилося … Люди аналізують статистику помилок по модулям і бригадам (але, правда, не по розробникам, це не колегіально), Цикломатичне складність програм, тощо і все це виливається в рішення типу “на що тепер важливіше витрачати гроші”.


Гіпертрофія і манія тестування


Як ви ставитеся до такої ідеї: кожному програмісту дати двох контролерів якості? Саме так справи і обстоять. Де не два, там півтора точно. Кожна зміна, природно, призводить до повного перетестірованію всієї системи (тобто перевіряють, а чи працює те, що вже працювало), тут це чомусь називають регресійним тестуванням. Якщо додано нову якість, його, природно, перевіряють теж. Зміни спершу накопичують (якась сума змін, яку треба протестувати, і є “версія”, з точки зору контролера). Просто так, поза версії, нічого змінити в польовому софтвера не дадуть. Основою є таблиці, де написано, що повинна робити система в тому чи іншому випадку і перебрані всі істотно різні варіанти введення. Одним з варіантів “введення”, наприклад, є вимикання харчування … Загалом, тестери (це проста робота, яка потребує освіти) працюють у 2 зміни і у вихідні, їх кількість збільшується, і це тенденція повчальна. Не все гаразд у Датському королівстві … Цікаво також постійне відчуття полупрітушенного конфлікту між тестерами і розробниками. Розробники теж тестують свої системи та засоби. Ми, наприклад, використовуємо робот-тестер – відмінний пакет QA-Partner фірми Segue. Він дозволяє запам’ятати мої, користувача, дії у вигляді скрипта, програми на Сі-подібному мовою. Далі я вставляю в неї цикли, виділяю загальні функції і будь ласка, робот готовий.


На цьому поки все.


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


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

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

Ваш отзыв

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

*

*