Программисты не решают задач бизнеса. Они создают и модернизируют программный продукт по техническому заданию заказчика. Убеждая всех, и себя, в том числе, что это и есть решение задач бизнеса.

Когда вы приезжаете в автосервис, вы пишете ТЗ? Конечно, многие из вас разбираются в автомобилях, и среди моих знакомых есть ребята, которые могут запросто разобрать и собрать обратно коробку передач. Но, все-таки, большинство из нас ставят задачу в виде «что-то стучит, когда еду быстрее 40 км/ч» или «плохо дует из дефлекторов, может кондиционер, или, не знаю, что там».

Если бы мастер в автосервисе на такой вопрос сказал что-то вроде «говорите конкретно, что надо сделать с вашей машиной», продолжили бы вы пользоваться его услугами? Думаю, что нет. Большинство из нас покупают машину не для того, чтобы в ней разбираться, и так поступают не только блондинки из анекдотов, или новые русские, которые (в тех же анекдотах) меняют автомобиль, когда заполнилась пепельница.

В работе с программистами у бизнеса выбора нет. И чем дальше, тем будет хуже. Еще не перевелись умельцы-энтузиасты, для которых решить вопрос самостоятельно – дело чести, но всеобщее разделение труда и засилье юридических-бюрократических подходов к делу быстро и надежно такой энтузиазм убивает.

Есть много материалов о том, как внедрение информационных систем помогло компаниям избавиться от потерь, сократить затраты, вырубить на корню воровство. Это прекрасно, когда получается избавляться от зла в таком большом объеме.

Моя статья — про зло помельче. Про саботаж внедрений, про вечное «я все правильно делаю, это ваша программа виновата», про раздутие штата, про мелкие корпоративные интрижки и сопротивление переменам.

Все в статье — из личного опыта, с примерами использования. На уникальность и полное раскрытие темы не претендую, высшей истины здесь нет, обобщений старался избежать, ничего не навязываю.

Просто опыт применения некоторых инструментов и примеры того, как они меня выручали.

Меня часто спрашивают о моей писанине. Не о конкретных событиях, или фактах, или вымыслах, изложенных в том или ином тексте, а о процессе создания текстов. Как я это делаю, когда, зачем, с какой скоростью, как совмещаю с работой, и есть ли у меня вообще работа, и т.д.

Я, как положено, на эти вопросы отвечал, но их стало так много, что решил изложить свой опыт в виде статьи. Цель ровно одна – централизованно рассказать о том, как я это делаю. Возможно, кому-то этот опыт поможет. А я просто буду давать ссылку на эту статью, когда получу очередной вопрос на тему «как ты пишешь всю эту хрень?».

Возможно, это последний мой текст, потому что вчера у меня в жизни случился крутой поворот.

Колодой, если верить писателям, раньше называлась «команда», которую набирал себе вор. У каждого человека в команде была своя «масть» — специализация и назначение. Вот что пишет об этом Борис Акунин в книге «Любовник смерти»:

«Пацаны рассказывали, что у настоящих деловых, кто по законам живет, шайка „колодой“ называется, и в каждой колоде свой кумплект. Кумплект — это восемь фартовых, каждый при своем положении. Главный — »король"; при нем маруха, по-деловому «дама»; потом «валет» — вроде как главный помощник; ну и прочие бойцы, от десятки до шестерки. А больше восьми человек в шайке не держат, так уж исстари заведено."

Меньше восьми людей брать смысла нет, будут пробелы в «компетенциях». Больше — нельзя, будет дублирование и потеря управляемости.



Как ни странно, тот же Джефф Сазерленд, один из авторов скрама, называл похожие цифры — от 5 до 9 человек. Хотя и не уточнял специализацию.

Ну да ладно. А мы продолжаем тему построения команд по ролям, на основе тестов Белбина.

Смешное слово — кодекс. Вам, наверное, смешно не будет, но я попробую объяснить. Однажды я работал в компании, сотрудники которой очень любили что-нибудь эдакое придумать — изменения, правила, нормы и т.д. Естественно, любые новшества фиксировались на бумаге, которой давали громкое, броское, запоминающееся название.

Можно, конечно, назвать бумагу «инструкция», «регламент» или «правила», но это так скучно… И никак не выделишься на фоне остальных. Поэтому слова использовались только красивые и звучные.

Первым было использовано слово «манифест». Точно помню — это был манифест отношений между продавцами и снабженцами. Потом был кодекс инженеров-конструкторов, конституция отдела внешне-экономической деятельности, и т.д. Каждый следующий выдумщик, естественно, хотел отличаться от предыдущих. Не круто, когда в компании два манифеста или три кодекса — чтобы понять, о какой конкретно бумажке речь, нужно расшифровывать. А когда у каждого новое слово — самое то.

Но вот беда — подобные слова быстро заканчиваются. Потом останутся только совсем экзотические, вроде «хартии» или «манускрипта». Я предложил ребятам слова резервировать — заранее объявлять, что мы, дескать, начинаем разрабатывать хартию кладовщиков, и отныне это слово никто не имеет права использовать.

Лично мне больше нравились аббревиатуры — их легко придумывать, и вариантов — намного больше. Например, у меня была Статистика Использования Функционала Автоматизации — набор инструментов, собиравший данные об использовании механизмов, созданных программистами. Еще был Журнал Отклонений Процессов Автоматизации, куда заносились косяки пользователей.

Но аббревиатуры всегда надо расшифровывать, иначе непонятно. Потому для статьи я решил выбрать слово «кодекс» — и слово всем понятное, и у самураев тоже кодекс был, и вроде звучит неплохо. Но теперь вы понимаете, что название «кодекс» — скорее, шутливое. А тема — важная. Чтение.

Ключевой проблемой любой организации являются изменения.

Где-то изменений слишком много, или наоборот — слишком мало, а может — нет идей, или есть, но их никто не реализует, или воплощение начинается, но никогда не заканчивается, а зачастую вообще, планируются одни изменения, а получаются другие, во многих же местах просто не замечается сама потребность в изменениях.

Если все эти проблемы объединить под одним словом, то словом этим будет «изменения». Именно с ними и проблемы. Тут вроде ничего доказывать не надо, все на поверхности лежит, но на всякий случай пару тезисов приведу.

Если у вас проблемы с продажами, вам нужны изменения. Очевидно? Вроде да. Или продукты продаете не те, что нужны рынку, или их слишком мало, или слишком много, или сроки срываете, или качество — недопустимо низкое, или продавцы хамят клиентам – неважно, это причины. Чтобы эти причины перестали оказывать влияние на систему продаж, нужны изменения.

Если у вас проблемы со снабжением, то вам нужны изменения. Очевидно? Вроде да. Или поставщиков других надо найти, или заказы формировать почаще, или, возможно, пореже, или партии уменьшить, или логистику улучшить, или перестать наемным транспортом пользоваться, или начать наемным транспортом пользоваться. Не так важно, что именно надо изменить, но что-то изменить — надо.

Если у вас проблемы с автоматизацией, то вам нужны изменения. Очевидно? Вроде да. Или платформу сменить, или программный продукт другой взять, или программистов нанять, или программистов разогнать, или порядочного аутсорсера найти (ха-ха), или перестать пользоваться колхозным интегратором и нанять федерального, или послать федералов и найти в своей деревне увлеченного фаната, или пересмотреть управление ИТ-отделом, или изменить мотивацию программистов. Не важно, что именно, но что-то надо менять.

Некоторые мои публикации вызвают у читателей массу вопросов. И не мои тоже. Особенно те, где человек пишет об опыте, выходящем, или выводящем за рамки текущей профессии.

Если эти вопросы сгруппировать и отсортировать, то ключевой звучал так: нафига? Нафига заморачиваться всей этой ерундой, что-то или кого-то измерять, сравнивать, организовывать команду или себя, какие-то методы дурацкие использовать, чушь всякую изучать дополнительную, можно же #простоработать (а чего, пусть хештег будет).

На эту тему – нафига? – очень много сказано во всяких книжках, статьях, видео и т.д. Вас эта информация, я думаю, не вдохновляет. Лично меня эта мотивационная масса тоже не впечатляла, когда я сам, несколько лет назад, задавался тем же вопросом. Ко мне тогда не книги, а люди, вполне конкретные приходили и говорили: ты – руководитель, у тебя коллектив, ты должен использовать передовые методы, чтобы превратить коллектив в команду.

Да-да, конечно-конечно – отвечал я – обязательно буду использовать, щас вот только запрос допишу. А сам внутри потешался – ишь ты, крутые управленцы, книжек начитались, сами ни фига не умеют управлять, а еще меня учат. К слову сказать, управлять они и правда не умели, и никаких методов из тех, что изучили, толком и не использовали.

А я вот, за каким-то хреном, в один прекрасный момент стал использовать. Почему? И почему вы не используете?

Чтобы это объяснить, придется рассказать небольшую часть своей биографии.

Я в жизни видел два типа бизнеса, которые развиваются хуже всех — франчайзи 1С и продавцы елок. Речь не о развитии вширь, когда просто поголовье программистов растет, а о внутреннем развитии. Об эффективности, короче.

Хотя, наверное, продавцов ёлок можно исключить из этого списка, они сумели меня удивить перед Новым Годом, продав мне настоящую ель. Раньше только пихты и сосны бывали. Я даже в интернете посмотрел, как отличить ёлку от пихты — реально, это была ель.

Так что в списке «Самые неразвивающиеся компаниии» остаются только франчайзи 1С. Там работает куча прекрасных людей, но то ли среда такая, то ли место проклятое — с ними что-то не так.

Они думают только о сегодняшнем дне. Возможно, виновата жесткая привязка к одному вендору, который разрабатывает и фреймворк, и прикладные решения. Никто же в здравом уме не будет в 21 веке строить долгосрочный бизнес, завязанный на один язык программирования, одну среду разработки, один рынок? А вот ковать железо, пока горячо — пожалуйста. Когда остынет, тогда и можно будет задуматься о чем-то серьезном.

Но мне, почему-то, кажется, что не все потеряно. Можно сделать лучше.

Чего воду в ступе толочь, вступления писать, сразу к делу.

Первый слой – кто хочет?

Многие из нас хотят что-то изменить в своем отделе, или компании, или даже в отрасли — профессиональной, например. Я это знаю, потому что давно наблюдаю и общаюсь — как в нашем кругу, так и в других, не связанных с программистами и вообще ИТ.

Но до реальных изменений дело доходит крайне – крайне редко. Это, наверное, даже не единицы процентов, а доли одного процента. Почему так?

Если собрать всех – например, программистов – и спросить: кто хочет что-то изменить в отделе, компании или отрасли? – то руки поднимут больше половины. Почему до конца, до реальных изменений, полезных и заметных, доходят эти несчастные доли? Где, и почему теряются остальные?

Этот процесс чем-то напоминает воронку, как в продажах. Помните же воронку продаж? Она показывает, сколько обращений переходят в деньги. Выглядит примерно так:


Ой, не то. Вот так:


Попробуем разобраться — кто, где отвалился и почему.

Итак, первый, самый широкий слой воронки – те, кто поднял руку.

Продолжаем тему управления качеством, начало здесь.

Что такое качество – допустим, разобрались, это степень соответствия требованиям потребителя. Вы, возможно, не согласны, по крайней мере с моей категоричностью, но вроде явных ляпов в этом определении нет.

Определение — понятно, но для управления качеством этого недостаточно. Это какая-то базовая, фундаментальная ценность, цель системы, а не руководство к действию. Что делать-то надо?

На что направить свои усилия, чтобы повысить качество? И качество чего надо повысить? Все слышали, что есть качество продукта, а есть – качество процесса. В чем разница? Что важнее?

А может, усилия надо направить на требования потребителя? Оставить качество на месте, а потребителя убедить, что его требования не обоснованы, и ему совсем другое нужно – не то, что он просит. Например, убедить покупателя, что колбаса из курицы – лучше, чем колбаса из мяса. Несложно ведь? Курица – диетическая, жира меньше, легче усваивается, да и стоит дешевле. Если убедить в этом покупателей, то они изменят свои требования, и качество продукта резко возрастет.

Это что такое получится? Управление качеством? В конечном итоге – да, но путь немного странный. Мы не качеством управлять будем, а требованиями. Есть вроде такая область знаний – управление требованиями? В ИТ, в частности. Хотя, если посмотреть телевизор, там только и занимаются, что управлением требованиями – кажется, это «пропагандой» называется.

Попробую рассказать то, что я успел узнать за свою жизнь про «нормальное» управление качеством.

Когда собирали доклады на голосование для участия в одной специализированной конференции, я хотел рассказать такую тему – как подсидеть директора по качеству. Это был бы конъюнктурный доклад про карьерный рост для программиста или ИТ-директора.

С одной стороны, рост в сторону директора по качеству кажется странным – это вроде совсем другая область. Но, как мы все уже знаем, из программиста может вырасти дофига чего интересного. Это не только я говорю – такая мысль звучит все чаще. Например, на той же конференции другого года был доклад на эту тему — как на западе ИТ-директора уходят в операционный менеджмент, не связанный с ИТ.

Тема управления качеством лично мне кажется невероятно, просто ужасно интересной и безумно полезной. Не потому, что управление качеством – как новый сезон Шерлока или тряхнувшего стариной Джека Бауэра. Просто управление качеством в нашей стране – это пример исключительно наглого, циничного, элементарного, тупейшего, и оттого удивительно эффективного шарлатанства.

Я не знаю ни одной другой отрасли знаний, в которой трудилось бы такое же количество людей, ничего не понимающих в своей профессии. Это не шутка, не гипербола. Я наблюдаю за этими ребятами больше 15 лет — еще с тех пор, когда сертификат ISO еще был престижной редкостью. Я работал с директорами по качеству и специалистами, консультантами и аудиторами, преподавателями ВУЗов и президентами ассоциаций, студентами и аспирантами. Сколько из них, по-вашему, знают и понимают, что такое управление качеством и как его осуществлять? А, вы же знаете, я выше написал – ноль. Ладно, пусть будет 1 % — наверняка где-то, случайно, или волею небес, есть люди, которые что-то понимают. Ну и вы, если внимательно и без предубеждения отнесетесь к управлению качеством, тоже будете понимать. Так, может, и до 2% дотянем.

Кто такие руководители, и зачем они нужны? Какая от них в жизни польза? Чем они вообще занимаются? А чем они должны заниматься?

С одной стороны, традиционно руководитель понимается как тот, кто управляет – строит планы, дает указания, контролирует сроки, орет громче всех, принимает решения и несет за них ответственность.

С другой стороны, есть мнение, что руководитель должен заниматься только развитием вверенного подразделения, не принимая участия в оперативном управлении.

С третьей стороны, есть самоуправление и бирюзовые организации, которые на практике доказали, что такая сущность, как руководитель, не нужна вовсе – это просто набор обязанностей, ролей и контрольных точек, которые легко размазываются между разными людьми.

Так кто же он такой, этот руководитель, и зачем он нужен? Руководитель нужен компании или компания нужна руководителю, как источник дохода? Может, он просто оправдывает свое существование, ведь результат того стоит – доходы руководителей зачастую несопоставимо выше, чем доходы обычных сотрудников.

Я использую специальную модель для оценки руководителей, с которой вам и предлагаю ознакомиться.

— Сергей! Сергей!

Сергей встрепенулся, оторвался от компьютера и снял наушники. Сбоку стояла Лена, менеджер по снабжению, с какими-то бумагами в руках и вопросительно на него смотрела.

— Чего? – спросил Сергей.

— Интервью.

— Чего?

— Мы с вами договаривались об интервью для корпоративного журнала.

— Блин, точно… Прямо сейчас? Я тут поработать хотел, специально вышел в каникулы…

— Прямо сейчас. – твердо сказала Лена. – Я, как вы заметили, тоже специально вышла в каникулы, и только ради интервью.

— А, да, точно… — Сергей начал волноваться. – Ладно, давайте. Надолго это?

— Не знаю. – пожала плечами Лена. – Вопросов много, быстрее начнем – быстрее закончим.

• Знание ООП и структуры данных;
• опыт разработки на Java для Android.;
• знание Android API, понимание архитектуры Android;
• знание основ HTTP, XML, JSON;
• опыт работы с системами контроля версий Git;
• опыт работы с Android Studio, Gradle;
• опыт работы с SQL базами данных;
• знакомство с принципами Material Design;

Узнали? Конечно, узнали. Это — одно из стандартных резюме программиста.

Лично мне такое резюме напоминает одну песню, а точнее одну строку этой песни: «Жигули! Едет и уже хорошо!».

Еще напоминает рекламу тех же Жигулей, где наличие ABS, датчиков дождя и света и т.д. выдается за конкурентное преимущество. Ну и лозунг знаменитый: «Таким и должен быть автомобиль!».

А программист таким и должен быть? Если хочет быть, как жигули – массовым, дешевым и «как бы и не машиной программистом», то да.

Но мы не такие, поэтому будем формировать и формулировать свое конкурентное преимущество – комплект увольнения.



Комплект увольнения – то, что остается с вами, когда вы меняете место работы. Как пел Юрий Шевчук, «Это то, что останется после меня. Это то, что возьму я с собой».

— С Новым Годом! С Новым Годом! – доносилось из-за угла, где располагался большой зал ресторана, арендованного для корпоративного торжества.

Сергей остановился, прислонился к стене и снова задумался. Идти на корпоратив чертовски не хотелось. В последний раз он посещал подобные мероприятия лет десять назад, тогда же в них и разочаровался. С тех пор весьма поднаторел в придумывании причин, по которым он ну никак не может прийти на корпоратив. С горем пополам еще посещал субботники, но видеть пьяные рожи коллег было невыносимо. На этот раз приперся только по одной причине – собственник попросил.

Еще немного подумав, и вспомнив о своем обещании Курчатову, Сергей собрался, оттолкнулся от стены плечом, обошел угол и оказался в зале. Выглядел тот так, как и положено – разноцветные длинные гирлянды вдоль стен, кучи воздушных шаров, искусственная елка, загадочно мерцающая маленькими лампочками, ну и большой логотип компании «Куб» — в виде куба, разумеется.

За большинством столиков уже сидели люди, лица некоторых отдавали багрянцем, несмотря на то, что корпоратив еще официально не начался. Сергей обвел взглядом зал, в поисках места для приземления. Как у них тут принято? Садись, куда хочешь? Или все распределено, как на свадьбах? Наконец, взор Сергея упал на столик, где сидела одна Татьяна. Чему-то улыбнувшись, Сергей решительно двинул к ней.

Flowcon, или Флакон – методика управления, в том числе – задачами. Потоком, проектом, разработкой, рутинными функциями, регуляркой и т.д.

Многие, узнав о методике и решениях на ее основе, задают вопросы – что да как, в чем суть, на основе каких «мировых практик» сделано, какие метрики используются, кому подходит, откуда вообще взялось. Я отвечал каждому индивидуально, но решил – все, стопэ, надоело писать одно и то же по сто раз. Программист я, или кто? Повторное использование может быть не только для кода, но и для информации. Напишу один раз, постараюсь ответить в статье на все вопросы, и будь что будет.

Лучше всего, мне кажется, в виде истории изложить, потому что рождение флакона тесно связано с моей, с позволения сказать, карьерой. Так и поступлю. Погнали.

Все знают, что такое айсберг – большой кусок льда, который плавает в океане. Все помнят, что не так с айсбергом – видна лишь небольшая его часть, которая над поверхностью воды, остальное скрыто. И сколько его там, этого остального – никто не знает.

Аналогичная ситуация – с данными в автоматизированных системах.

Не знаю, как вы, а я люблю ставить эксперименты над людьми. Обычно я мнения людей не спрашиваю, но на этот раз эксперимент был проведен по их собственной просьбе. Люди захотели, чтобы я сделал им новую систему мотивации. Ну я и сделал.

Статья несколько длинновата, т.к. я постарался изложить не только вход и выход, но и процесс разработки системы, возникающие по дороге вопросы и как мы их решали. Возможно, наш опыт будет полезен вам — если не целиком, то какие-то его части.

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

Есть на свете такая штука, называется «бизнес-программирование». Я вам о ней еще не рассказывал. И не уверен, что вам она будет интересна.

Бизнес-программирование — это программирование бизнеса, как системы. Вот вы же чего-то программируете? Сервис там, сайт, мобильное приложение, корпоративную систему. Она работала, никого не трогала, а вы — раз, и изменили чего-то, и стало лучше, быстрее, удобнее. Ну, или… Всяко ведь бывает.

Аналогично можно менять бизнес, принципы те же самые. Только есть отличия в деталях. Например, там есть люди, которые ни черта не хотят делать. И даже слушать вас не хотят. И вообще не хотят ничего, кроме получки, сериала про ментов и пиваса.

Короче, статья экспериментальная. Понравится — напишу еще. У меня целый учебник есть по бизнес-программированию. Не понравится — хрен с ним, переживу. Итак, погнали.

Сергей зашел в кабинет собственника – тот сидел на своем месте, а через стол расположилась Ольга.

— Сергей, приветствую! – Курчатов встал, протянул руку через стол. – Присаживайся!

Сергей сел рядом с Ольгой, вежливо улыбнулся и приготовился слушать. Настроение было не сильно рабочим – до увольнения оставалось четыре с половиной дня.

— Сергей, не буду ходить вокруг да около. – начал Курчатов. – Я предлагаю тебе остаться в нашей компании. И не просто остаться, а возглавить ее.

Сергей шумно вздохнул. Опять начинается…