Я давно зарекся бложить про работу, но сегодня решил сделать исключение и написать о таком явлении, как "японский процесс".
Для начала: что же такое "процесс"? Под этим словом в данном случае я подразумеваю процесс производства ПО (програмного обеспечения), но вообще, наверное, сюда можно отнести производство любого товара, будь то тапочки на заводе в Бурятии или изготовление пиццы в Макдоналдсе. Конечно, во всех случаях процесс работы будет разительно отличаться, но определение будет более-менее общее: это набор правил, метрик, документов и т.д., который позволяет компании отслеживать свое развитие.
Во время моей работы на Моторолу мы постоянно были в жестких рамках "процесса". Помимо собственно написания кода нужно было поддерживать требования, заполнять формы с отчетами (не только для мотороловских боссов, но и для оценок работы компани), следить за выполняемостью метрик, укладываться в сроки, делать пропозалы для других команд и т.д. К этому всему прилагалось огромное количество документов (TRS'ы, SRS'ы, FAD'ы, SUIS'ы, etc. Кто знаком, тот прослезится). Для поддержания хорошего качества в коде необходимо тестирование, которое придерживалось своих процессов и метрик (Test suit'ы, Test case'ы, TCS'ы, etc.).
Слишком жесткий процесс - тоже не всегда хорошо. Если бы разработчики тратили большинство своего времени на поддержание процесса в компании, то никто никогда не увидел бы результата их работы (предположительно). Поэтому считается, что процесса должно быть "в меру": не слишком много, чтобы не отнимать времени от основных задач, и не слишком мало, чтобы компания видела и могла адекватно оценить результаты своей работы.
В большинстве российских компаний (фирм, предприятий) про налаженный процесс вообще не слышали: главное - написать циферки в бухгалтерском отчете, и хватит. Поэтому я всегда в проектах стараюсь обозначать рамки и правила для всего, начиная с наименования проекта (почему одна работа называется "Для Вани", а другая - "2009-12, Козуб"?), наименования файлов и рабочих документов, структуры репозитория и т.д. и заканчивая сбором собственных метрик и написания минуток собрания. Для чего весь этот геморрой? В первую очередь, чтобы исключить хаос и упорядочить работу. Во-вторых, чтобы адекватно оценить ресурсы и свои возможности на разработку программы. В-третьих, чтобы не срывать контракты. В-четвертых, чтобы "соблюсти лицо" (всегда приятней работать с компанией, которая знает, на что и в какой срок она способна, а также может грамотно разбить цель на задачи). Есть еще причины, но для своего рассказа мне достаточно будет этих четырех.
Наверно, многим интересно, насколько жесткий процесс в японских компаниях. Ведь не даром Москва, спаленая пожаром Япония - очень технологичная страна, с большим уровнем проникновения технологии в социум, с выской планкой качества совбственных продуктов.
Для примера возьму несколько случаев и опишу, как бы они происходили в японской компании и в "мотороловской" (взял, что ближе). Под "мотороловской" компанией я буду иметь ввиду обобщенный имидж фирмы, которая придерживается своего стандартного процесса разработки.
Случай 1.
Неожиданно выяснилось, что в софтине должна быть такая-то функциональность (например, "если пользователь тыкает сюда, то должно вылазить вот это"). Время на выполнение - "три недели" (команда программистов и тестирования) и "неделя" (начальник). Сроки отодвинуть нельзя - заказчику уже пообещали "будет все через неделю, сэр!"
В японской компании, после брифинга об этих изменениях работники расползаются по своим местам и всю неделю сидят за мониторами до 3-х ночи, пытаясь сообразить рабочий код. На второй день после начала работы над изменениями все ходят с черными кругами под глазами, шатаются и сталкиваются в проходах, спят на рабочих столах в обеденный перерыв. В итоге - прилепленная кое-как функциональность (код не писался в расчете на новые функции) отгружена заказчику, после чего в течение еще двух-трех недель заказчик находит ошибки, и сыпется штуки 3-4 патчей.
В "мотороловской" компании такой случай вряд ли бы имел место. Во-первых, потому что не бывает такого - "неожиданно выяснилось, что надо!" Все документы составляются и согласуются заранее, до начала разработки. То есть, когда программисты уже начали кодировать - они знают свою цель, видят, как ее достичь и что нужно сделать, чтобы на выходе получилось то, о чем договорились. Если (форс-мажор!) необходимо внести изменения в функциональность - то процедура составления, анализа и согласования документации начинается заново, соответственно, отодвигается по времени конец работы.
Более того, в "мотороловской" компании начальник (отдела, проекта, фирмы) никогда не пообещает заказчику какие-то сроки без обсуждения с командой, или по крайней мере, с ответственными за разработку. Ситуация, когда босс "лучше знает, сколько времени надо программировать" - нонсенс.
Случай 2.
Начинается новый проект. Архитекторы планируют программу, программисты - изучают платформу, всякая шпана - составляет списки документов и формирует репозиторий. Время на весь проект (от руководства компании) - 7 месяцев.
В японской компании все выглядит по-взрослому: проводятся собрания, заполняются минутки, назначаются встречи с заказчиками для выяснений потребностей, часть личного состава в это время занимается изучением платформы и составлением требований к программе. Требования пишут грамотно: технические, пользовательские, требования к програмным интерфейсам, пользовательские интерфейсы и т.п. Составляются правила "Как именовать проект", "Распределение личного состава по офису", "У кого какая должность на проекте", "Как именовать переменные и названия функций в коде", "Процесс верификации кода" и т.д.
И потом, по прошествии 5 (пяти) месяцев начинается собственно программирование: работники расползаются по своим местам, сидят за мониторами до 3-х ночи, пытаясь сообразить рабочий код. На второй день после начала работы над изменениями все ходят с черными кругами под глазами, шатаются и сталкиваются в проходах, спят на рабочих столах в обеденный перерыв. Три раза в месяц изменяется содержание документа "Распределение личного состава по офису", всех пересаживают на новые места "с целью повысить качество разработки". На правильно именование переменных и функций всем наложить, потому что верификаций все равно не проводится (не успевают).
Менеджер проекта выпрашивает у руководства компании еще один месяц "на доведение программы до ума", но заказчикам все равно отгружается сырая версия - потому что объем работ примерно напоминает объем работ по созданию майкрософтовского Ворда (MS Word). Дружными плотными рядами следуют патчи, исправления, дополнения к "базовой версии" ("базовая версия" - это то же самое, что Блоктот по сравнению с Вордом).
Этот случай из разряда "перегнули с процессом", в "мотороловской" компании нереален.
Случай 3.
Во время выполнения проекта обнаруживается, что недостаточно изучены пользовательские амбиции. Ну что ж, спишем на форс-мажорные обстоятельства. Назначается собрание, на котором начальником отдела принимается волевое решение убрать половину из уже написанного кода (т.е. говоря языком начальника отдела - вычеркнуть "ненужные" функции, вряд ли они потребуются заказчикам). "Главный" программист (тот, которого все почему-то считают за главного) убеждает начальника и "подчиненных", что "вот так сделать - будет лучше" (хотя налицо несоответствие этих решений и уже работающей программы).
В японской компании - на этом дело не заканчивается. Через две-три недели разработки оказывается (под давлением "главного" программиста), что пользовательские амбиции изучены плохо, и очень сильно разнятся с представлениями ("главного" программиста) о скорости работы программы в разных местах. Приходится откатывать код назад, выполнять програмную логику другими способами, даже если логика программы нарушается.
И опять не конец. Еще через пару недель до проекта снизоходит начальник отдела и предлагает вернуть все как было и следать "вот так" (как раз те "ненужные" функции, которые были вычеркнуты волевым решением раньше). При этом, начальник отдела совершенно не в курсе архитектуры приложения, типов данных, логики работы и ресурсов на переделку все взад.
В "мотороловской" компании... Никогда не вычеркивается ничего только потому, что кому-то там показалось это "ненужным". "Вот так будет лучше" - по определению не бывает без анализа и согласия как минимум большинства (потому что "лучше" характеризует субъективную оценку). "Главный" инженер на полпути не будет спохватываться и заявлять что-то в духе "Я тут сегодня чуть не подскользнулся на ступеньке, и мне показалось, что программа работает не так, как должна. Давайте-ка все поменяем..." Указания начальника отдела, с которым специально регулярно проводятся совещания (на предмет "а не появилось ли в вашей светлой голове очередных бредовых мыслей?"), не будут тотчас же рассматриваться в свете переделки всего приложения...
Случай 4.
Нужно за неделю добавить в программу функциональность (допустим, "чтобы можно было считывать данные с карты").
В японской компании это все. Целое, законченное требование. Которое должно выполняться.
Конечно же, со стороны программистов робко начинают появляться вопросы типа "А откуда считывать?..", "А что такое "карта"?..", "И куда считвать?..", "А что потом с этими данными делать?..", "А как их пользователю показывать?..", "А каких действий ждать от пользователя?.." и мильон других.
Изначальные требования не проработаны (это я еще мягко, ага), никто не знает никаких деталей (кроме того человека, от которого поступило требование), менеджеры бегают по каждому вопросу к подрядчику, программисты не знают, что же им действительно сейчас делать (и строят поредположения о сроках в районе "от двух дней до трех недель"), начальник торопит с оценками... В кутерьме не готовится документация (технические требования, тестирование и т.д.).
Нужно описывать, как такое решается в "мотороловской" компании?
Случай 5.
Эх...
Подозреваю, что не во всех японских компаниях такое отношение к процессу. Наверно, особо большая роль формальностей в тех компаних, которые работают на внешний рынок. Но в таком случае задаешься вопросом: а как, собственно, вот это все появилось? Дома из стали и стекла? Сони со своей плейстейшн?.. Тошиба? Саньо? (ныне поглощенная Панасоником что ли...) Сам Панасоник?.. Кэнон? Никон?..
Большинству российских компаний недостает не то, что процесса - понимания, зачем он нужен. В японских компаниях процесс присутствует, порой с очень даже серьезными очертаниями, но с ним совершенно бессмысленно управляются. Японцы - те еще муравьи, работают в муравейнике для блага муравейника. Если бы они еще и работали так, как думают, что они работают - было бы вообще супер.
