Собственно говоря Subj.
Есть какая-то тема по поводу IT, программирования, бизнеса, персональных финансов и иже с ними, которая задевает вашу нежную душу и о которой мне просто необходимо написать?
Жду с нетерпением идей и предложений 😉
Собственно говоря Subj.
Есть какая-то тема по поводу IT, программирования, бизнеса, персональных финансов и иже с ними, которая задевает вашу нежную душу и о которой мне просто необходимо написать?
Жду с нетерпением идей и предложений 😉
Представим себе, что есть корпорация с достаточно длинной вертикалью менеджмента. Ну уж не знаю… скажем 5+ слоев. И пусть где-то на верху есть некоторое количество людей (в топ менеджменте или в совете директоров), которые владеют какой-то частью компании (читай заинтересованы в достаточно долгосрочном успехе компании).
Есть одна особенность «потоков» информации в такой компании. Обычно тех самых владельцев кормят из ложечки говном информацией, которая ну скажем имеет очень слабое отношение к реальности. Кормят их те самые 4+ слоев, которые находятся под ними.
Происходит это по той простой причине, что в своем уме, очень небольшое количество менеджеров хотят признавать свои ошибки (особенно, если это может сказаться на их ЗП, бонусах, должности). Ну и логично, что на верх подается несколько искаженная информация и пройдя через N слоев искажения — она уже содержит истину в гомеопатических объемах.
Например классика такой ситуации — это когда в корпорации делается большой IT проект и собираются его выкатить через два года и что проект будет нереально крутым. Весь топ менеджмент (включая совладельцев) продолжают верить в это и инвестировать деньги, до тех пор пока 2 года спустя оказывается, что деньги просраны, а проект не просто далек от выпуска, а за это время стал жутким монстром, который проще выбросить, чем довести до ума. При этом достаточно большее количество рядового состава из опоков (QA, программисты и иже с ними) вполне таки подозревали чем это все закончится еще год, до того, как это дойдет до менеджмента.
Так вот, появилась у меня забавная идея. Удивлен, что ее не слишком практикуют. Позволять впрямую контактировать через несколько слоев менеджмента. Чаще всего люди, максимум знают (и общаются) с боссом своего босса. Редко кто общается через 2, а тем более через 3+ уровня.
Так вот — идея, позволить это делать раз в некоторое время. Например, раз в неделю можно пообщаться через 1 уровень, раз в месяц — через 3, раз в квартал — через 5, раз в пол года — через 7 уровней. Не думаю, что будет так много людей, которые захотят этот делать, так что беспокоиться о том, что CEO вдруг засыплют письмами.
С другой стороны, это даст возможность менеджменту (а в идеале владельцам) получать информацию с разным уровнем искажения и делать выводы на ее основе.
Вчера на одном дыхании прочел книгу под названием «RTFM» (она на русском, всего 100 страниц). Очень рекомендую прочитать. Книга о том, как правильно строить сервисный бизнес.
Сказано в книге все правильно и умно, но я бы сказал, слегка упрощенно. Упрощенно в смысле, что автор дает правильный метод работы, но абсолютно опускает проблемы, которые возникают даже при правильном методе работы.
Тем не менее, еще раз рекомендую прочитать книгу. Кстати, а вот и блог автора — блог.
Второе, хочу дать ссылочку на статью (теперь уж на английском) — Avoiding Development Disasters. Очень точно описываются почему большие и слишком хорошо финансированные проекты чаще всего заканчиваются полным крахом.
И третья, мысль, которая вышла из вчерашнего спора с другом. Очень многие (особенно хорошие) разработчики говорят, что код должен является единственной и главной документацией (самоописывающий код). Что если нужно создавать отдельную документацию — это плохо, так как появляется второе «отображение» кода, которое может не обновляться и устаревать и расходится с кодом, что только усложняет понимание.
Я с этим категорически не согласен. Только небольшой проект очень хорошего написанного и прокомментированного кода можно понять без дополнительной документации. Когда же у вас на руках проект с миллионом строк кода, то для того, чтобы понять что и где происходит зачастую нужно будет проглядеть пол проекта (прилагая много усилий по удержанию в голове того, что вы еще видели и ни с чем не связали). При этом простая диаграмка, показывающая разбиение на модули и помудульная диаграмка, которая показывается основные взаимодействия внутри модуля может сохранить дни (если не недели), на том, чтобы понять, как проект работает.
О… Пока писал, еще одна мысль всплыла. Опять же, у программистов зачастую есть проблема ownership’а. То есть, они чувствуют, что владеют/отвечают за какой-то кусок работы. И постепенно в этом куске работы, они начинают делать все так, чтобы ИМ было удобно (не думаю о остальных, учитывая что они сами работают над этим участком). Мысль, которую я некоторое время назад сформулировал — владеть нужно проблемой и за нее отвечать, а код должен таки оставаться общий. Именно поэтому код должен комментироваться, документироваться и придерживаться другими методами доступным для остальных разработчиков.
Есть у меня пару человек, которые активно мне поставляют… нет не дурь (сами видно, заразы все выкуривают), но забавные корпоративные истории. Так, что выкладываю одну из них, буквально с минимальной обработкой. Все повествование ведется от лица поставщика (местами даже диллера 🙂
__________
В общем, преамбула совмещается с фабулой и будет многа букаф. Это скорее просто жалобы на тяжелую жизнь, но возможно тебе это знакомо. Короче говоря, у меня нас есть несколько тимов, каждый из которых пишет свой продукт и OEM тим, которые все эти продукты собирает, кастомизируют и раздают оем клиентам. Рулит этим тимом Configuration manager.
На прошлой неделе наш Configuration manager поднял плач Ярославны «как у нас все хуево с качеством, всем пиздец». Ну ок. В целом, я с ним согласен, но почему так получилось — вопрос интересный. Получилось так, что по целому ряду стратегических решений топ менеджмента, принятых год-полтора назад, стандартный подход — нахуй качество, надо рынок завоевывать, а остальное потом исправим. Ну, рынок завоевали, тока теперь на поддержание этой кучи говна в жизнеспособном состоянии тратятся огромные ресурсы, кастомизации под каждого клиента приходится приделывать болтами и сварочным аппаратом где-то сбоку.
Так вот, прошлонедельный плач был по поводу того, что тестеры из оем находят много багов, относящихся к самому продукту. И мы мол не знаем, что именно получает команда оем от команд продуктовых. Наш Configuration менеджер поднял дискуссию на высоком уровне и в итоге наш VP engineering’а произнес сакраментальную фразу: «А давайте померяем качество!»
Ну давайте. Встречный вопрос — а как мы будем мерять качество? Он грит, а хуй его знает. Вот пойдите, мои верные слуги, простите, менеджеры, и придумайте, как мы будем мерять качество. Мол, похоже QA хуево работают, но хер его знает. Мне изначально было все это похую, потому как я за qa не отвечаю и вообще это проблемы project manager’а.
В общем, как тут принято начинать работу над любым вопросом (хоть формы зеркала в сортире)? Правильно — соберем митинг. Пригласим всех ну или не всех. В общем, собрались мы митинговать — я, мой начальник, Configuration менеджер, директор инжениринг и прочая братия.
Project manager говорит — тебе нужно сказать, что ты как product manager хочешь сделать для измерения качества? Я говорю, охуенные заявочки. А ниче, шо инжениринг — это вы, а не я? Я вам как product manager могу тока сказать, что качество наверное хуевое, а как его мерять — это уже ваши дела. Померяйте и принесите. Они грят -а мы не знаем, как мерять качество. Вот если нам скажут, как мерять, мы померяем, и отчитаемся о проделанной работе.
Тут вступает Ленский, в смысле Configuration менеджер. Мне, сообщает, все равно, как и кто будет мерять, но мне надо, чтобы когда моему тиму сдают в релиз продукт, сообщали, какое у него качество. и так, чтобы было четко и понятно. а еще лучше говорит, чтобы ты сам там со своими пацанами разбирался, задерживал релизы, а мне приносили тока когда все готово.
Мой начальник, понимая, что эта хуйня и его касается, воспользовался авторитетом и послал их нахуй тут же с таким предложением. Мол, наша задача вообще ставить задачи и acceptance criteria. а то что вы там в своем инжениринга собрались мерять — это вы там сами разбирайтесь.
Короче этот волейбол продолжался два рабочих дня. В промежутках между этими безумно продуктивными дебатами я (хаха, наивный мальчег) ходил по людям и пытался найти, кто вообще обладает подобными знаниями и отвечает за эти вещи. пошел сначала к инженирингу. они замахали руками, зажмурились и закричали «не, мы сами нихуя не знаем». ну ладно, пошел к QA. QA менеджерша перепуганным голосом сказала, что она сделает все, что ей скажут, особенно если расскажут, как делать.
Мне все это надоело, я пошел к моему боссу и говорю — вот такая хуйня. Я в жизни никогда qa не был, какие у них там метрики, методы и тд я понятия не имею. Он говорит, ладно, ну их всех нахуй. Раз никто нихера не знает, будем сами с тобой придумывать. Собрали очередной митинг. Вызвали все тех же танцоров.
Началось все уже привычно: А как нам померять качество? Я грю, ну самое простое, что приходит в голову — отсортировать тест кейсы по группам и собрать статистику по pass & fail. Все радостно закивали головами. Но тут вступил мой босс. Не, говорит, это все хорошо, но не люблю я эти тест кейс статистики. Вот когда я пишу acceptance criteria, я знаю, что это я написал и знаю, сколько они покрывают. а кто там писал ваши тест кейсы я не знаю, и как они написаны я тоже не знаю. Может они там покрывают 20% возможных use cases (надо заметить, у него есть основания так говорить). Давайте, говорит, лучше определим 10-20 основных функциональных областей (типа как epics), отдадим каждому члену команды на тестинг и послушаем выводы.
Тут вступает project manager: не, если программистов послушать, так у них все работает идеально, а если не работает, то это исключение и дурацкий юз кейс (что впрочем, тоже логично).
Я говорю, а может мы не будем изобретать велосипед? Судя по всему,никто из нас не знает, что значит померять качество. Но вполне возможно, есть какие-то работы на эту тему, подходы, тулзы. Я даже готов почитать это все, чтобы с умным видом всех вас просветить позже. даже если нихуя там нету, что тоже может быть. Но естественно это не могло пройти, потому как Configuration менеджер тут же застонал, что у него сейчас релиз, а как мы вообще можем релизить, не зная качество, так что померять надо прямо сейчас и срочно.
Я говорю, а как мы до этого релизили? На что следует ответ: ну так это же было неправильно! Мы же растем, мы должны знать, что мы релизим. Ок, отвечаю я, а как на счет того, чтобы мы сейчас неправильно отрелизили по старинке, не страдали хуйней, а по ходу следующих несколько недель я почитаю, подумаю, да и вообще что-то придумаем. Он на меня посмотрел так, как будто я лично признался в массовых убийствах христианских младенцев и сообщил: ТЫ ЧТО, ХОЧЕШЬ РЕЛИЗИТЬ, НЕ ЗНАЯ, ЧТО ТЫ РЕЛИЗИШЬ??? И ЭТО НЕ СГНАЛ ТРЕВОГИ ДЛЯ ТЕБЯ???
Бля, чувак, да у нас под тысчу открытых багов. Я знаю, что мы релизим полное гавно и мы его не разгребем сейчас. И скорее всего никогда не разгребем, потому как у нас одни обязательства. Да, отвечает он,- но мы хотя бы сможем померять и будем знать, что и как в общем, громко поплевавшись мы решили совместить наши гениальные идеи. Решили, что я напишу список критичных функциональных областей, отправлю тимам, инженеры с их менеджерами решат, что и как делать, а дальше по каждой из этих областей мы соберем и проценты по тест кейсам и общие наблюдения. Из-за этого релиз был торжественно отложен. Как же релизиться, если не померяли?
И теперь финишная прямая
Я написал письмо, отправил тимам с их инженерным менеджментом, а он — менеджмент тот — пришел ко мне и сказал: а мы че-то не поняли, в каком виде вы это хотите получить? @#$@#$@#$…. В виде процента по тест кейсам бля и личным соображениям бля. Хотя я думал, вы там что-то с QA придумаете. Ответ последовал ожидаемый: так а шо QA, они качество мерять не умеют. Как скажете, так и померяем.
Я устало махнул рукой, и сказал — ну вот пусть и меряют по своим тест кейсам.