Моя статья будет представлять собой больше набор историй из жизни и некоторые выводы из них. Основная проблема, которая меня сейчас волнует: как сделать так, чтобы довольны были и заказчики, и разработчики, и прибыль была и карма цела. Конкретного окончательного рецепта у меня нет, есть несколько отрицательных примеров и намеченные цели, которыми хочется поделиться.
Я занимаюсь разработкой с 2003 года (в основном web-приложения), до этого 4 года преподавала в ОмГУ основы программирования для 1-го курса математического факультета. На данный момент у меня пошел 3-й год в роли совладельца собственной небольшой аутсорсинговой компании. Рассказывать буду исключительно о своем опыте по двум причинам: я успела побывать в трех различных типах компаний, которые могу сравнить, и считаю, что пересказ чьего-то опыта не дает полной картины.
Возможно, для кого-то я буду выглядеть вот так:
В конце 2003 года я с одной стороны поняла, что мне остро не хватает настоящей практики разработки, поскольку одно преподавание и учебные задачи не дают полноценной картины жизни индустрии, с другой встал во весь рост вопрос заработка. Проблема оторванности преподавателей программирования от жизни известна всем не понаслышке. Это одна из причин постоянно муссируемого среди программистов мнения, что обучение в вузе абсолютно бесполезно и надо просто идти и начинать работать. На эту тему я могу говорить долго, поэтому сейчас просто скажу: я с этим мнением не согласна, а дискуссии оставим на потом. Я решила, что надо пойти, набраться опыта в практике и потом вернуться в вуз уже обладая определенным багажом знаний, чтобы ликвидировать разрыв между академическим образованием и потребностями индустрии.
Выразилось это в том, что с 2009 года я читаю в ОмГУ спецкурс для студентов 3-5 курсов под названием “Современные практики разработки ПО”, где обучаю их на практике многим навыкам, которые требуются в реальной работе и которых не хватает свежим выпускникам, когда они ищут свою первую работу. В частности это: командная работа, процессы разработки, инструментарий (системы контроля версий, автоматизированные сборки, таск-трекеры, непрерывная интеграция). Немало внимания уделяется и написанию качественного кода, разумному документированию и логгированию, юнит-тестированию и т.д. В рамках курса студенты выполняют командный проект на 2-3 человека, используя различные веб-фреймворки на Java, Python и Ruby, которые мы по ходу дела еще и сравниваем между собой.
Итак, в 2003 году я уволилась из ОмГУ и устроилась в отдел разработки ПО в довольно успешную компанию, занимающуюся проектированием магистральных нефте- и газопроводов, где занималась автоматизацией внутренней работы.
На тот момент в Омске это был один из самых крупных налогоплательщиков. Кроме того — были 2 больших отдела по разработке ПО для внутренней автоматизации. Один из них даже разрабатывал софт для внешнего заказчика — АК “Транснефть”. Там я узнала, что такое внутренняя политика с ориентацией на персонал и как это все рушится с передачей управления людям, которые не создавали компанию, а просто инвестировали в уже готовое предприятие, получив контрольный пакет. Читая много позже книгу Ди Марко и Листера “Человеческий фактор”, я смеялась сквозь слезы, когда они описывали аналогичную ситуацию, где полностью демотивированные люди увольняются, а те, кто еще не уволился, сидят и думают: “Все уже ушли, один я как идиот еще сижу, пойду тоже уволюсь, и гори все синим пламенем”.
В 2009 году на фоне ухода огромного количества отличных специалистов-проектировщиков и изыскателей — основы компании — я получила предложение поработать в зарождающейся аутсорсинговой компании, которая на тот момент состояла менее, чем из 10 человек.
Я была 3-м по счету разработчиком, принятым туда. Меня сразу немного насторожило, что разработчиков всего 3, зато в штате, не считая генерального директора, есть юрист, маркетолог, кадровик, бухгалтер и менеджер проектов. К сожалению, печальная история этой конторы в итоге немало оказалась связана с подобным же распределением должностей на протяжении всего ее существования.
Наиболее анекдотичным был найм ресурс-менеджера, когда рентабельность уже была на грани фола, который приставал ко всем каждый день с бесчисленными вопросами, чем мы занимаемся и не могли бы мы использовать те полчаса, которые у нас вдруг образуются, для помощи ребятам на другом проекте. Думаю, программистам не нужно объяснять, к чему это приводило. Объяснить руководству, что эти меры бессмысленны, нам тогда не удалось.
Тем не менее именно здесь я получила весьма интересный опыт общения с зарубежными заказчиками а также благодаря моему другу Михаилу Подгурскому (хабраюзер kmmbvnr) — который любезно разрешил мне использовать слоган своего профиля в качестве темы доклада — существенно расширила круг технологий, которые если и не знаю глубоко, то имею весьма неплохое представление, для того чтобы оценить применимость того или иного подхода для решения поставленных заказчиками задач.
В 2010-м году наша печально известная далеко за пределами Омска компания потерпела крах и была объявлена банкротом, заказчики, с которыми мы на тот момент работали, оказались весьма обескуражены таким положением дел и попросили разработчиков, которые с ними работали, продолжать уже без конторы. Так в Омске родилось несколько фрилансерских объединений, в том числе и моя нынешняя небольшая компания началась с этого заказа, над которым мы работали вплоть до конца 2011 года.
Параллельно с организацией собственной компании я устроилась работать в одну из крупнейших аутсорсинговых компаний теперь уже не только России, но и Европы.
Здесь было все: крупные заказчики, достаточно высокие по омским меркам зарплаты, полный соцпакет. На том проекте, где работала я, — тишь да спокойствие, никаких тебе авралов, никаких сверхурочных. Наоборот — частенько приходилось самим придумывать, чем себя занять. Ситуацию лучше всего иллюстрирует следующая картинка:
Парадокс заключается в том, что там действительно есть достаточно большое количество очень хороших программистов. Один из них, который был нашим тимлидом, на мой взгляд лучший из тех, с кем мне приходилось работать когда-либо. И они не уходят, просто находят, чем бы заняться помимо основной работы. Например, дают массу ценных советов новичкам, которые постоянно к ним обращаются.
Однако мне достался довольно скучный проект, о котором рассказ ниже, толку от своей работы там я видела все меньше, а совмещать руководство компанией и собственный наемный труд становилось все сложнее. Поэтому в январе 2011 года я наконец-то решилась уволиться и окончательно заняться только собственной компанией.
В компании нас немного, у нас нет — кроме меня и Ивана Немытченко (хабраюзер nem) — никаких управленцев, бухгалтер на аутсорсе, никаких кадровиков и менеджеров по ресурсам. В этом, разумеется, есть и плюсы и минусы, но пока живем так. Мы с Иваном до сих пор пишем код, занимаемся проектированием архитектуры веб-приложений, ведем стажировку, руководим проектами как менеджеры, общаемся с заказчиками. Выглядит это примерно так (не нашлось картинки с большим количеством инструментов, а жаль):
Иногда даже вот так:
Помимо того, что мне удалось получить представление о различных видах заказной разработки, я принимала участие в стартаперских тусовках, мы с Иваном прорабатывали несколько своих идей, пару-тройку стартапов пытались запустить — пока не слишком успешно по понятным причинам — помимо создания собственно кода, надо все это еще и продвигать, и привлекать пользователей, на что у нас сейчас пока нет ресурсов.
Мы с командой регулярно посещаем различного рода ИТ-конференции в Москве, Новосибирске, Екатеринбурге, Самаре. И последнее время меня начал терзать один вопрос, который постоянно хочется задать докладчику, который рассказывает об общих подходах к процессу разработки, о каком-то применении комбинации технологий и т.д. и т.п.: “Окей, это все здорово, а какую проблему заказчика вы этим решили?”.
Добил докладчик с codefest-2012 Максим Ткачук со своим докладом “Hard rock design” codefest.ru/program/2012-03/hard-rock-design. Жаль, что его доклад заявили на секцию PM + HR и его пришли послушать не все разработчики, которые там были, а в основном менеджеры и дизайнеры. А он рассказывал о том — со своей колокольни, конечно, — что дизайнер должен принимать участие во всем процессе работы над проектом, начиная от первоначального сбора требований, занимать проактивную позицию, глубоко понимать назначение разрабатываемого продукта и аудиторию пользователей (потребителей). Говорил очень эмоционально, чувствовалось, что проблема выстрадана и постоянно приходится сталкиваться с дизайнерами, которые этого не понимают. А я сидела в зале и мысленно меняла слово “дизайнер” на “разработчик”, “тестировщик” и т.д.
Собственно та самая проблема, которая окончательно сформулировалась у меня только недавно звучит так: основная масса членов команды не желает вникать в проблемы заказчиков и пользователей, а менеджмент и заказчики не считают нужным информировать команду о многих аспектах решаемой задачи, считая это необязательным.
Симптомами наличия проблемы являются:
● заказчик считает, что команда не обязана знать о некоторых проблемах с привлечением пользователей, финансированием, проводимых презентациях и т.д., дело команды — писать код, а о вопросах бизнеса голова должна болеть совсем у других людей;
● в начале переговоров по проекту заказчик больше интересуется наличием формальных сертификатов вроде CMMI, чем знакомством с реальными членами команды, зачастую предпочитает общение только с менеджером и аналитиками;
● разработчики говорят: “Я хочу просто писать код, дайте мне четко поставленную задачу и я все сделаю. Про проблемы заказчика пусть болит голова у аналитика и менеджера” («телепаты в отпуске»);
● команда действует по принципу: делаем ровно то, что попросили, нам заплатят, а дальше нас не касается;
● менеджеры считают разработчиков оторванными от жизни существами, которых надо как-то развлекать и мотивировать, поскольку основная их работа — скука смертная и нужны специальные меры, чтобы они не закисли;
● сами разработчики считают основную работу скукой смертной и для сохранения мотивации занимаются сторонними опен-соурс проектами и мелкими стартапами, направленными не столько на заработок, сколько на получение отдушины от рутины;
● разработка проекта сопровождается тонной документов, но большинство рядовых сотрудников не в состоянии описать типичных пользователей продукта и никогда их не видели;
● общение между любыми представителями различных ролей напоминает поле боя;
● представитель любой роли может с ходу назвать чем именно он недоволен в работе менеджера и представителя любой другой роли в команде;
● в первую очередь каждый член команды может сформулировать чужую ответственность и только потом назвать свою;
● первой и основной задачей любого члена команды является прикрытие одного места сковородкой путем завышения оценок и спихивания ответственности за срыв на других.
Последствия для команды (в долгосрочной перспективе):
● мотивация снижена до критической отметки, никто не стремится сделать задачу как можно лучше;
● любые решения принимаются по принципу «лишь бы не влетело»;
● в особо тяжелых случаях принятие решений сопровождается несколькими этапами подписания бумаг;
● не приветствуется никакая инициатива по улучшению кода, архитектуры, внутренних процессов, инициатор в большинстве случаев получает вопрос «тебе что – больше всех надо?»;
● при первой же возможности наиболее перспективные члены команды меняют проект;
● единственной мотивацией становится денежная и карьерная, за достаточно долгий срок в команде могут собраться самые меркантильные конъюнктурщики либо те, кого не интересует ничего, кроме стабильной зарплаты и возможности уйти домой в 18:00.
Последствия для внутреннего менеджмента:
● нужны специальные меры по контролю за выполнением задач;
● за долгий срок команду покидают наиболее инициативные, те, кто остается, уже не вывозят;
● ответственность за срывы сроков лежит в основном на менеджере, мотивировать команду не допустить срыва можно только кнутом и пряником.
Последствия для менеджмента заказчика:
● заказчик многократно переплачивает за завышенные сроки и текучку кадров;
● качество продукта отличное только по бумагам, на деле код и архитектура могут быть ужасными, следовательно заказчик переплачивает за неудовлетворительное качество;
● если пользователи – широкий круг людей, добровольно выбирающих продукт, возможно уменьшение их числа по изложенным ниже причинам.
Последствия для конечных пользователей:
● нет прямого контакта с исполнителями и возможности быстро дать обратную связь;
● потребности удовлетворяются не полностью, чаще всего пользователей приходится специально обучать для использования продукта, поскольку он далек от их стандартных юскейсов;
● порядок и сроки выполнения заданий по добавлению нового функционала не соответствует потребностям пользователей.
Чтобы проиллюстрировать вышесказанное расскажу о некоторых проектах, над которыми мне приходилось работать в роли разработчика или менеджера.
Итак, фирма занимающаяся проектированием магистральных трубопроводов. Отделу разработки ПО дали задачу написать небольшую программу для отдела экологии. Исходные данные:
Чуть подробнее об отделе:
Написана своя библиотека 2D-графики, в планах 3D (на дворе уже OpenGL и все такое). Написана своя хитрая структура хранения данных в памяти – этакая комбинация связанного списка и структуры с прямым доступом, т.е. массива. Для доступа используется очень низкоуровневый подход, никакой абстракции нет и в помине, сплошная адресная арифметика, причем не только в потрохах, но и на уровне API. Написан свой грид, который на вход получает адрес в памяти и все свои данные берет при помощи вычислений адресов относительно этого начала. Сдвиг где-то внутри в 1 байт рушит все. Наиболее эпично его название: “myGrid”.
Молодому бойцу – т.е. мне – предлагают использовать все это как составные части будущей программы на Builder, которая заменит текущий зоопарк экселевских расчетов. Заказчики – тетеньки от 45 и выше (начальники) и девочки около 25 (рядовые исполнители) – мыслят исключительно в категориях расчетов, каковые они воспринимают как не связанные между собой части и с их точки зрения разработка инкрементальна – расчеты повторяются один за одним и занимают примерно одинаковое время.
Около месяца я честно делала все на Builder, введенные через мега-грид данные попадали в мега-структуру в памяти, которая при сохранении на диск просто скидывалась как есть в бинарный файл и потом поднималась при чтении из файла в память как есть. Но я восстала. Заявила начальнику отдела, что задача откровенно предполагает использование базы данных – особенно учитывая требуемый многопользовательский режим. Еще месяц боев и я получила разрешение. Как раз собирались создавать корпоративную информационную систему (КИС) на Java+Oracle и я получила возможность делать систему как часть этой КИС.
Чем больше я погружалась в задачу, тем больше понимала, что расчеты мало того, что взаимосвязаны, так еще и данные для них в большинстве своем есть либо в различной нормативной и справочной литературе, либо поступают от сотрудников других отделов. Появилось понимание, какая система нужна экологам на самом деле и она мало походила на то, что они описали. Я торчала в их отделе, задавала вопросы, выходящие далеко за рамки данных мне расчетов, в итоге постепенно я вникла в механику работы всего института.
Я сделала то, что им на самом деле было нужно, гораздо больше того, что просили, но это заняло намного больше времени, чем предполагалось в начале. Полгода на первую версию с базовым для остальных расчетом и 2,5 года до полного завершения. За это время меня чуть не уволили за отсутствие видимого результата в первые 1-2 месяца (не помню уже точно) а также были существенно испорчены отношения с начальником отдела и тогдашним директором по ИТ, который был не из программистов, а из инженеров-проектировщиков.
Затем я начала обивать пороги начальства, пытаясь запустить процесс автоматизации и построения модели всего процесса изысканий и проектирования, поскольку на тот момент, как мне представлялось, я была практически единственным человеком, который целенаправленно изучал работу всех отделов института с точки зрения потоков входных и выходных данных на уровне цифровой модели проекта. Был еще отдел КИС, но они больше интересовались типами текстовых документов, а чертежи рассматривали как обычные бинарные файлы. Для меня же основной была модель, а все чертежи и текстовые документы – всего лишь отчетами, которые можно построить в любой момент, имея модель.
В итоге эта глобальная система так и не появилась по куче причин бюрократического и экономического характера, а я уволилась. К слову – кусочная автоматизация этого процесса имеется в других проектных институтах, а одна из ИТ-компаний зарабатывает на коммерческом продукте, который покрывал на момент последнего моего знания о нем (2010 год) процентов 60 того, что мне представлялось в 2006 году. Есть еще несколько продуктов, покрывающих изыскательские работы (геодезию, геологию и т.д.), использующих модель внутри, а чертежи в формате AutoCAD получающих как отчет. Но они, к сожалению, не имеют продолжения в проектировании трубопровода.
Вернемся к задаче. Вроде бы все было сделано правильно – пользователи получили продукт, который удовлетворил их потребности даже в большей степени, чем они могли рассчитывать. Но. Они получили его гораздо позже, чем хотели. Чем это для них обернулось? Большими потерями времени на рутину и как следствие — сверхурочной работой в течение лишнего года.
Какие ошибки были допущены:
1. Сбор требований посредством опросов начальства и изучения экселевских файлов.
2. Выбор малоизученной разработчиком на тот момент технологии разработки, что затянуло появление первой версии.
3. Попытка сделать первую версию системы сразу мега-универсальной.
Глобальной причиной всех этих ошибок было то, что я слишком увлеклась своими целями, забыв о целях заказчика. Я хотела сделать хорошую и универсальную систему, попутно изучив новые для меня технологии. А заказчик хотел всего лишь сократить время на выполнение расчетов и уходить домой вовремя.
Как должен был поступить идеальный сферический разработчик в вакууме:
1. Начать с изучения бизнес-домена путем полного погружения в работу отдела на некоторое время с целью изучения всех процессов изнутри вплоть до выполнения основных юскейсов рядового сотрудника отдела самостоятельно.
2. В течение недели, максимум двух, написать несколько макросов на Visual Basic, которые обеспечили бы использование результатов одних расчетов в качестве исходных данных для других, а так же оцифровать наиболее часто используемые справочники в эксель, что дало бы ускорение работы примерно на треть.
3. Имея рядом уже частично счастливого заказчика, спокойно разработать настоящую систему, уже понимая все юскейсы и основные риски, что дало бы ускорение процесса разработки тоже не менее, чем на треть.
На первый взгляд пример не вписывающийся в описанную выше проблему и симптоматику. На второй взгляд так оно и есть. Поскольку имело место быть наличие разработчика весьма мотивированного на изучение проблем заказчика и попытки их решить наилучшим возможным способом (не считая начальной ошибки с макросами, точнее с их отсутствием). Проблема в том, что все остальные, кто был вокруг, были совершенно не мотивированы на улучшение общей ситуации в компании. Вопрос, действительно ли мне больше всех надо я слышала регулярно. И в один прекрасный момент терпение лопнуло.
Каковы выводы из всей этой истории?
1. Пользователя надо знать в лицо. Причем не только менеджеру и бизнес-аналитикам, а всей команде.
2. В процессе создания функциональных и интерфейсных требований по максимуму должна участвовать вся команда.
Наличие этих условий даст команде возможность проявить творчество, а личное знакомство с пользователями и их задачами позволит наилучшим образом решать эти задачи. Когда пользователь абстрактен и безличен, никто не вкладывает душу в продукт для него.
Но что делать в случаях, когда нет доступа до реального пользователя?Можно завести резинового пользователя. Шутка, конечно. Для этого придуманы специальные практики разработки портретов пользователей. Команда создает реальный портрет человека, с именем, возрастом, профессией даже привычками, а так же страхами, которые могут возникнуть при пользовании продуктом, и какую пользу им этот продукт может принести. Возникают игровые моменты, шутки, внутренние мемы. Практика достаточно неплохо показывается на тренинге AgileCamp от компании Scrumtrek.
На тему знакомства с пользователями и изучения их конкретных потребностей могу назвать еще два кейса. Буквально недавно мы сидели в офисе заказчика и имели возможность пообщаться с живыми пользователями будущей системы. И девочка-дизайнер интерфейсов несколько раз повторила фразу: «Ой, ну как же все-таки здорово, что можно вот так вот поговорить с пользователями! Обычно ведь не знаешь, кто это и как именно они будут в итоге пользоваться продуктом».
Собственно дело было в том, что пока мы общались с менеджментом заказчика, они предлагали сделать супер-универсальную аналитическую систему, которая бы позволяла показывать диаграммы и сводные данные по любым мыслимым разрезам и чем-то напоминала бы большой эксель, в котором сейчас пользователи и работают с таблицами графиками. Так сложилось что мы прилетели в Москву и собрались все вместе обсудить уже фактически окончательно проговоренные требования и подписать договор. Проблем было 2: с нашей стороны отсутствие четкого понимания сроков, поскольку некое универсальное нечто оценить сложнее, требования более расплывчаты, а со стороны команды, разрабатывающей интерфейс пользователя – ощущение, что такой универсальный интерфейс большинству пользователей будет не нужен и непонятен.
Мы с самого начала собирались предложить пригласить конечных пользователей и постоять с ними вместе у доски со стикерами и маркерами, провести story-mapping (опять же отсылаю к AgileCamp от Scrumtrek-а). Хоть это и не вышло, но тем не менее мы пригласили пользователей и с каждым из них поговорили, попытавшись понять, каковы его основные юскейсы и ожидания от использования системы. Итогом этого стало то, что супер-универсальность отмели и получили несколько четких юскейсов, которые закрыли 80% самого важного функционала. Все это позволит гораздо быстрее выпустить рабочий прототип, который уже принесет бизнесу пользу.
Похожая история произошла совсем недавно с другим нашим заказчиком. Он хороший программист, ставший с какого-то момента техническим директором. Поэтому он ставил нам по сути не бизнес-задачи, а предлагал конкретные архитектурные решения. Пытался добиться от нас опять же супер-универсальной и супер-модульной системы, которая делает все. Никаких конкретных кейсов из него толком вытащить не удавалось и конечных пользователей нам тоже не представили.
Полгода назад он был в Омске и мы провели полдня, составляя Lean canvas и делая Story-mapping. В итоге выбрали некий кейс для первого прототипа и все вроде бы шло практически идеально первые несколько итераций. Однако в какой-то момент вдруг поступило неожиданное требование, о котором не было даже намека на story-mapping-е, — создать некие справочники: организаций, геолокаций и т.д. Команда не задалась вопросом – зачем, а заказчик не счел нужным пояснить. А еще через 2 недели вдруг выяснилось, что у заказчика на носу срочное важное событие, для подготовки к которому ему требуется продукт. Он хотел заранее посадить пользователей наполнять систему данными, чтобы все успеть, но поскольку не предупредил об этом заранее, система не была готова к работе пользователей именно по тем юскейсам, которые им требовались в данный момент.
Какие выводы из этих двух историй:
1. Надо не только знать своих пользователей в лицо, но и получить с них информацию о самых главных вариантах использования системы, которые закрывают 80% их потребностей и должны быть реализованы в первую очередь.
2. Лучше ограничить влияние технического менеджмента со стороны заказчика настолько, насколько это возможно; настаивать на общении с людьми от бизнеса и конечными пользователями для наилучшего понимания целей создания продукта.
3. Нужно задавать вопросы заказчику относительно сроков назначенных демонстраций или других важных событиях, поскольку он может не подумать об этом сам. При этом важно понимать, что иногда дате наступления события, когда продукт будет использован для показа, должны предшествовать неделя-две для альфа-тестирования конечными пользователями.
Сразу после проектного института я работала в бездарно обанкротившейся впоследствии небольшой аутсорсинговой компании, в которой одно из первых заданий мы с менеджером совместными усилиями зафакапили. Система состояла из двух частей: записи видеопотока с камер наблюдения со стримингом в двух режимах – онлайн и в записи — и веб-админки для настройки параметров камер, систем хранения записанного видео и всевозможных нотификаций о событиях.
Менеджер знал, что у нас есть один большой технический риск – запись и стриминг видео. Были серьезные опасения, что за месяц разработчик не успеет изучить форматы основных камер и написать что-то удобоваримое для демонстрации заказчику возможности записи видео-потока. Поэтому он надеялся, что я быстро наклепаю админку, которой можно будет замылить глаз заказчику, он увлечется замечаниями и пожеланиями и на некоторое время забудет про видео, что даст второму разработчику время для маневра.
Однако, все эти соображения были лишь в голове у менеджера. Разработчики же видели конечный срок – 3 месяца – и особо не волновались. С заказчиком лично мы практически не общались, этим занимался менеджер. До нас же информация доносилась уже в виде распоряжений, с каковыми мы спорили и кое-где делали по-своему, оттягивая намеченные менеджером сроки. Мы наверняка бы уложились в общий срок (плюс-минус, конечно). Но мы не имели никакой работающей системы через обещанный месяц, поскольку и я, и второй разработчик преследовали свои цели, не шибко заботясь о заказчике – для нас он был всего лишь ником в скайпе да емэйлом. Поэтому я выбрала для разработки новый для меня фреймворк, чтобы убить двух зайцев сразу. Менеджер это дело не пресек, хотя и подозревал, что я не успею вместе с изучением уложиться в срок.
В итоге авторитет менеджера и компании в-целом в глазах заказчика сильно пошатнулся, начались перерывы в общении, отложился первый денежный транш.
Можно было бы сказать, что проблема в отсутствии правильного процесса разработки. Вот был бы дескать скрам и наступило бы счастье. Однако дело здесь все-таки не в самом процессе или его отсутствии – итерации с описанным скоупом с какими-никакими критериями приемки у нас были – дело в том, что мы не решали все вместе проблему заказчика. У меня абсолютно точно не болела голова о недополученных заказчиком прибылях за счет сдвига дедлайна.
Учитывая предыдущий опыт с экологами, я бы совершенно точно прониклась бы и стала думать в том направлении, в котором хотелось бы даже не менеджеру, а заказчику, поскольку менеджера все-таки больше интересовал вопрос прикрытия филейной части сковородкой, чем запуск прототипа с целью апробации и возможно даже коммерческого использования с ограничениями возможностей. Но – он не подал как следует, а я не проявила достаточного любопытства. Новый фреймворк с его техническими особенностями на тот момент интересовал меня гораздо больше. Его выбор тоже оказался неудачен в итоге, изучение отняло непозволительно много времени. Для этой задачи можно было выбрать один из динамических языков и фреймворк типа Django или Rails.
Какие выводы из этой истории?
1. Команда должна быть в курсе всех рисков и проблем бизнеса заказчика (зачем ему запуск и именно в эти сроки, какой именно функционал его устроит для прототипа).
2. Команда должна быть в курсе мотивов собственной компании (насколько проект важен для репутации, портфолио или финансового благополучия).
3. При обсуждении и выборе технических решений технический менеджмент должен в первую очередь руководствоваться проблемами бизнеса, а разработчикам разъяснять, что упражняться с новыми фреймворками на заказчиках негуманно. Чтобы разработчики тем не менее не теряли интерес к изучению нового, надо давать какие-то возможности применить новые технологии, но на своих внутренних проектах или давать время на open source разработки.
Это приведет к тому, что разработчики уже не смогут откровенно игнорировать и заказчика, и менеджера, поскольку будут чувствовать себя в какой-то степени в одной лодке и с тем, и с другим, понимая насколько успех проекта отразится и на них самих, поскольку успешный проект в портфолио – повод для гордости, не говоря уже о возможном улучшении финансового положения и компании, и конкретного разработчика.
За две недели до банкротства мелкого аутсорсера я перешла работать в филиал крупной аутсорсинговой компании.
Попала я туда интересно. Я пришла на собеседование просто из любопытства, для того, чтобы проверить свои скиллы на соответствие потребностям весьма уважаемой в городе компании. И меня совершенно очаровал интервьюер. Мы очень мило с ним поговорили о различных технических вопросах и я поняла, что он очень крут, у него можно поучиться многому. Он, как выяснилось, тоже меня оценил достаточно высоко, чтобы хедхантеры начали активно заманивать. На окончательное решение повлияло то, что мой интервьюер будет тимлидом команды разработки, в которую мне предстояло войти.
Я честно предупредила директора филиала и менеджера, что у меня есть собственная небольшая команда, которой я буду заниматься параллельно, получила согласие и стала вливаться в коллектив. Проектная команда в 45 человек, из которых разработчиков меньше трети меня немного удивила. Тестировщиков при этом было существенно больше, несколько выделенных аналитиков, у каждой команды свой лидер и над всеми – архитектор, менеджер проекта и менеджер программы.
Проект оказался долгожителем. Он существовал 30 лет на Фортране, затем в 2000-2001 году его переписали, сделав веб-проектом на Java+Oracle. При этом был полностью сохранен внешний вид интерфейса. Не столько потому, что к нему привыкли пользователи, сколько потому, что ни один разработчик до конца не понимал, в чем суть системы и что означают все эти экраны для ввода данных. За время существования проекта в компании на нем сменилось больше 100 разработчиков, сколько тестировщиков и аналитиков я не знаю. В итоге в той команде, в которую я попала, не было ни одного человека, который до конца бы понимал систему. Даже аналитики, которые бодро сыпали непонятными мне терминами, не могли ответить на большинство вопросов о целях и потребностях пользователей.
Все это привело к тому, что разработка велась методом наложения заплаток. Документы по системе, создаваемые аналитиками и тестировщиками, зачастую не соответствовали текущему состоянию кода, поскольку не у каждого разработчика хватало терпения их прочитать и выполнить все, что там написано. По некоторым юскейсам у заказчика и команды разработки были две различных картины одной и той же функциональности.
Именно на этом проекте я наблюдала большинство симптомов, озвученных мной выше. Мое желание разобраться в бизнес-домене вызывало недоумение. Ведь куда проще выполнять небольшую задачу, не вникая в то, что якобы ее не касается. Меня же беспокоило то, что система с точки зрения юзабилити была худшим примером, который мне когда-либо доводилось видеть. Время на обучение пользователя работе с ней было огромным. Пользователь вынужден был держать в голове огромное количество допустимых значений параметров и их сочетаний, поскольку система не выдавала никаких подсказок и даже валидация огромной формы часто выдавала просто надпись «Ошибка!», перегружая страницу с очисткой всех введенных данных, после чего несчастный пользователь вынужден был вводить все заново.
При этом в основном люди, которые работали на проекте, технически были очень компетентны, разбирались в огромном количестве тонкостей используемых и смежных технологий. Тем не менее, в глазах у многих я видела тоску. Компания, собравшая чуть ли не лучших разработчиков города, очень странно распоряжалась этими ресурсами. Были проекты, где небольшая команда разработки и буквально 1-2 тестировщика работали сверхурочно в постоянном режиме в то время как мы слонялись часто из угла в угол, не зная, чем себя занять, когда код отдавался в тестирование, а следующая итерация еще не начиналась. Но менеджеры программ на своих совещаниях изо всех сил держали своих людей, не отдавая их тем, кто в этом остро нуждался, поскольку понимали – обратно им могут их и не отдать, даже если будет надо. Очень многие разработчики, сидя внутри компании, зарабатывали на фрилансе, тратя на это основную часть рабочего дня.
Итогом стал уход нескольких достаточно инициативных сотрудников, которые в итоге заняли руководящие позиции в динамично развивающихся компаниях города либо уехали из него. Они были готовы реализовывать свои идеи и внутри предыдущей компании, но эти инициативы остались без внимания руководства, ибо на высоком уровне менеджмента проблемы конечных пользователей и даже внутренние проблемы команды разработки уже абсолютно не видны.
Для себя я сделала следующие выводы, которые в данном случае в большой степени спорны, поскольку найдется огромное количество людей, которые чувствуют себя совершенно комфортно в большой иерархически построенной структуре:
1. В подобной структуре масса людей, которые предпочитают не брать на себя ответственность и ценят «стабильность», становится критической. Это приводит к тому, что в те редкие моменты когда требуется с шашками наголо быстро забрейнштормить новый проект, никто не готов к такому виду деятельности. Поэтому в такие компании приходят проекты такие же скучные и долгоиграющие, как и те, которые уже находятся в разработке.
2. Если же проекты другого типа все-таки просачиваются, на них вроде бы поначалу все идет весело и интересно. Чаще всего разработчиками там становятся вновь прибывшие сотрудники либо пассионарии, сбежавшие с других проектов. Однако соседство полусонных команд с других проектов, которые постоянно собираются в коридорах поболтать или на кухне почаевничать, либо тех кто явно левачит в рабочее время очень быстро заставляет задуматься – а почему собственно я должен работать на износ, когда кругом куча народу получает зарплату практически ни за что и имеет кучу свободного времени. Это снижает мотивацию довольно быстро. Дальше людей начинает держать только зарплата и перспективы повышения в должности. Однако, очень многие в итоге все-таки уходят в стартапы, небольшие, но веселые команды или во фриланс.
3. Доля счастья на душу программистского населения в маленьких командах, не имеющих нескольких уровней иерархии управления, гораздо выше. Лично мне такие команды импонируют гораздо больше. Находиться среди людей с горящими глазами гораздо приятнее. Поэтому я бы очень не рекомендовала совмещать внутри одной компании упомянутые типы команд и проектов.
4. Скорость реакции на пожелания заказчика в маленьких командах выше, что повышает уровень счастья заказчика. Не всякий заказчик пока еще готов «рискнуть» и нанять маленького, но гордого аутсорсера. Однако же таковые на наше счастье находятся.
Формула
Для меня и моего партнера она состоит из следующих компонентов:
• Разработка продукта, который задуман в первую очередь чтобы помочь пользователям решить какую-то очень важную проблему, а получение прибыли является побочным эффектом – просто такой полезный сервис не может не стать популярным. Продукт в идеале должен быть настолько интересным, чтобы им хотелось заниматься даже и бесплатно в свободное время. Поэтому возможность работать над ним за деньги – настоящее счастье для команды. В идеале продукт – свой собственный.
• Небольшая, но очень high level skill команда, в которой просто нет лишних людей. Каждый – энтузиаст и евангелист, помимо основной работы активно занимается саморазвитием, ведет блог просветительского характера, контрибутит в интересный open source проект либо делает свой собственный.
• Команда вникает в бизнес заказчика либо проблемы конечных пользователей настолько, что способна говорить с ними на одном языке и рассматривать продукт с точки зрения business value, адаптируя все процессы и технические решения под потребности бизнеса/пользователей.
• Заказчик настолько адекватен, что доверяет команде в выборе технических и процессных решений, позволяя ей самой решать, каким образом обеспечить потребности бизнеса в рамках обозначенного бюджета.
• Большое количество рутинных операций вроде деплоя и прогона разноплановых тестов автоматизированы настолько, что команда имеет достаточно времени для работы над действительно интересными и сложными вещами, требующими приложения мозга.
• У команды находится время проверять гипотезы насобаках прототипах и проводить разбор полетов по окончании каждого этапа разработки, обмениваясь опытом удачных и неудачных решений с другими командами как внутри компании, так и за ее пределами – например, на конференциях. Если есть возможность вести параллельную разработку нескольких вариантов решения с возможностью сравнительного анализа и выбором наиболее удачного в итоге – это вообще сказка.
Неплохая подборочка в стиле «Спасибо, кэп!». Собственно, для нас это пока некоторый идеал, к которому мы изо всех сил стремимся. Я ни в коем случае не претендую здесь на истину в последней инстанции. Существует масса успешных с точки зрения прибыли компаний, в которых нет ни одного из упомянутых пунктов. Либо огрызки от одного-двух из них. Но я хочу подчеркнуть, что я говорю не о максимизации прибыли, а совершенно о других вещах. Это момент в большой степени философский. Сами по себе деньги не особо нужны. Мешок денег на необитаемом острове бесполезен. Человеку нужно ощущение счастья, которое дается отнюдь не деньгами как таковыми.
Собственно цель моего выступления на конференциях и этой статьи — обсудить с коллегами аспект взаимодействия бизнеса и команды разработчиков, актуальность проблемы непонимания и недоверия в этом взаимодействии. Поэтому в первую очередь я готова задать вопрос читателям – актуально ли для вас то, о чем я говорила? Есть ли желание обсуждать эти темы подробнее?
Вопрос не праздный. Мы собираемся провести конференцию, построенную на несколько других принципах, чем те конференции, которые мы посещали последние пару лет. В частности: dump.it в Екатеринбурге, codefest в Новосибирске, devconf в Москве, agiledays и agilecamp. Конференция намечена на 29 сентября.
Идея состоит в том, чтобы разбить доклады на секции не по специализациям в команде: разработчики, тестировщики, дизайнеры, менеджеры, и не по используемым технологиям. Хочется объединить людей в секции по типам задач бизнеса, рассмотрев на каждой секции конкретные кейсы в комплексе. Людям, работающим в энтерпрайзе, на банки и прочие крупные компании не интересно слушать тех, у кого заказчиками являются стартаперы с ограниченным бюджетом, которым нужно быстро изготовить прототип для получения раунда инвестиций либо для проверки гипотезы и замера KPI. Хочется, чтобы люди делились между собой подходами к организации процессов разработки и выбору технических решений, исходя из потребностей решаемой задачи.
Спасибо всем, кто нашел время прочитать. Буду рада любым каверзным вопросам и советам по поводу затронутой темы.
Я занимаюсь разработкой с 2003 года (в основном web-приложения), до этого 4 года преподавала в ОмГУ основы программирования для 1-го курса математического факультета. На данный момент у меня пошел 3-й год в роли совладельца собственной небольшой аутсорсинговой компании. Рассказывать буду исключительно о своем опыте по двум причинам: я успела побывать в трех различных типах компаний, которые могу сравнить, и считаю, что пересказ чьего-то опыта не дает полной картины.
Возможно, для кого-то я буду выглядеть вот так:
Об опыте работы
В конце 2003 года я с одной стороны поняла, что мне остро не хватает настоящей практики разработки, поскольку одно преподавание и учебные задачи не дают полноценной картины жизни индустрии, с другой встал во весь рост вопрос заработка. Проблема оторванности преподавателей программирования от жизни известна всем не понаслышке. Это одна из причин постоянно муссируемого среди программистов мнения, что обучение в вузе абсолютно бесполезно и надо просто идти и начинать работать. На эту тему я могу говорить долго, поэтому сейчас просто скажу: я с этим мнением не согласна, а дискуссии оставим на потом. Я решила, что надо пойти, набраться опыта в практике и потом вернуться в вуз уже обладая определенным багажом знаний, чтобы ликвидировать разрыв между академическим образованием и потребностями индустрии.
Выразилось это в том, что с 2009 года я читаю в ОмГУ спецкурс для студентов 3-5 курсов под названием “Современные практики разработки ПО”, где обучаю их на практике многим навыкам, которые требуются в реальной работе и которых не хватает свежим выпускникам, когда они ищут свою первую работу. В частности это: командная работа, процессы разработки, инструментарий (системы контроля версий, автоматизированные сборки, таск-трекеры, непрерывная интеграция). Немало внимания уделяется и написанию качественного кода, разумному документированию и логгированию, юнит-тестированию и т.д. В рамках курса студенты выполняют командный проект на 2-3 человека, используя различные веб-фреймворки на Java, Python и Ruby, которые мы по ходу дела еще и сравниваем между собой.
Итак, в 2003 году я уволилась из ОмГУ и устроилась в отдел разработки ПО в довольно успешную компанию, занимающуюся проектированием магистральных нефте- и газопроводов, где занималась автоматизацией внутренней работы.
На тот момент в Омске это был один из самых крупных налогоплательщиков. Кроме того — были 2 больших отдела по разработке ПО для внутренней автоматизации. Один из них даже разрабатывал софт для внешнего заказчика — АК “Транснефть”. Там я узнала, что такое внутренняя политика с ориентацией на персонал и как это все рушится с передачей управления людям, которые не создавали компанию, а просто инвестировали в уже готовое предприятие, получив контрольный пакет. Читая много позже книгу Ди Марко и Листера “Человеческий фактор”, я смеялась сквозь слезы, когда они описывали аналогичную ситуацию, где полностью демотивированные люди увольняются, а те, кто еще не уволился, сидят и думают: “Все уже ушли, один я как идиот еще сижу, пойду тоже уволюсь, и гори все синим пламенем”.
В 2009 году на фоне ухода огромного количества отличных специалистов-проектировщиков и изыскателей — основы компании — я получила предложение поработать в зарождающейся аутсорсинговой компании, которая на тот момент состояла менее, чем из 10 человек.
Я была 3-м по счету разработчиком, принятым туда. Меня сразу немного насторожило, что разработчиков всего 3, зато в штате, не считая генерального директора, есть юрист, маркетолог, кадровик, бухгалтер и менеджер проектов. К сожалению, печальная история этой конторы в итоге немало оказалась связана с подобным же распределением должностей на протяжении всего ее существования.
Наиболее анекдотичным был найм ресурс-менеджера, когда рентабельность уже была на грани фола, который приставал ко всем каждый день с бесчисленными вопросами, чем мы занимаемся и не могли бы мы использовать те полчаса, которые у нас вдруг образуются, для помощи ребятам на другом проекте. Думаю, программистам не нужно объяснять, к чему это приводило. Объяснить руководству, что эти меры бессмысленны, нам тогда не удалось.
Тем не менее именно здесь я получила весьма интересный опыт общения с зарубежными заказчиками а также благодаря моему другу Михаилу Подгурскому (хабраюзер kmmbvnr) — который любезно разрешил мне использовать слоган своего профиля в качестве темы доклада — существенно расширила круг технологий, которые если и не знаю глубоко, то имею весьма неплохое представление, для того чтобы оценить применимость того или иного подхода для решения поставленных заказчиками задач.
В 2010-м году наша печально известная далеко за пределами Омска компания потерпела крах и была объявлена банкротом, заказчики, с которыми мы на тот момент работали, оказались весьма обескуражены таким положением дел и попросили разработчиков, которые с ними работали, продолжать уже без конторы. Так в Омске родилось несколько фрилансерских объединений, в том числе и моя нынешняя небольшая компания началась с этого заказа, над которым мы работали вплоть до конца 2011 года.
Параллельно с организацией собственной компании я устроилась работать в одну из крупнейших аутсорсинговых компаний теперь уже не только России, но и Европы.
Здесь было все: крупные заказчики, достаточно высокие по омским меркам зарплаты, полный соцпакет. На том проекте, где работала я, — тишь да спокойствие, никаких тебе авралов, никаких сверхурочных. Наоборот — частенько приходилось самим придумывать, чем себя занять. Ситуацию лучше всего иллюстрирует следующая картинка:
Парадокс заключается в том, что там действительно есть достаточно большое количество очень хороших программистов. Один из них, который был нашим тимлидом, на мой взгляд лучший из тех, с кем мне приходилось работать когда-либо. И они не уходят, просто находят, чем бы заняться помимо основной работы. Например, дают массу ценных советов новичкам, которые постоянно к ним обращаются.
Однако мне достался довольно скучный проект, о котором рассказ ниже, толку от своей работы там я видела все меньше, а совмещать руководство компанией и собственный наемный труд становилось все сложнее. Поэтому в январе 2011 года я наконец-то решилась уволиться и окончательно заняться только собственной компанией.
В компании нас немного, у нас нет — кроме меня и Ивана Немытченко (хабраюзер nem) — никаких управленцев, бухгалтер на аутсорсе, никаких кадровиков и менеджеров по ресурсам. В этом, разумеется, есть и плюсы и минусы, но пока живем так. Мы с Иваном до сих пор пишем код, занимаемся проектированием архитектуры веб-приложений, ведем стажировку, руководим проектами как менеджеры, общаемся с заказчиками. Выглядит это примерно так (не нашлось картинки с большим количеством инструментов, а жаль):
Иногда даже вот так:
Помимо того, что мне удалось получить представление о различных видах заказной разработки, я принимала участие в стартаперских тусовках, мы с Иваном прорабатывали несколько своих идей, пару-тройку стартапов пытались запустить — пока не слишком успешно по понятным причинам — помимо создания собственно кода, надо все это еще и продвигать, и привлекать пользователей, на что у нас сейчас пока нет ресурсов.
О проблеме
Мы с командой регулярно посещаем различного рода ИТ-конференции в Москве, Новосибирске, Екатеринбурге, Самаре. И последнее время меня начал терзать один вопрос, который постоянно хочется задать докладчику, который рассказывает об общих подходах к процессу разработки, о каком-то применении комбинации технологий и т.д. и т.п.: “Окей, это все здорово, а какую проблему заказчика вы этим решили?”.
Добил докладчик с codefest-2012 Максим Ткачук со своим докладом “Hard rock design” codefest.ru/program/2012-03/hard-rock-design. Жаль, что его доклад заявили на секцию PM + HR и его пришли послушать не все разработчики, которые там были, а в основном менеджеры и дизайнеры. А он рассказывал о том — со своей колокольни, конечно, — что дизайнер должен принимать участие во всем процессе работы над проектом, начиная от первоначального сбора требований, занимать проактивную позицию, глубоко понимать назначение разрабатываемого продукта и аудиторию пользователей (потребителей). Говорил очень эмоционально, чувствовалось, что проблема выстрадана и постоянно приходится сталкиваться с дизайнерами, которые этого не понимают. А я сидела в зале и мысленно меняла слово “дизайнер” на “разработчик”, “тестировщик” и т.д.
Собственно та самая проблема, которая окончательно сформулировалась у меня только недавно звучит так: основная масса членов команды не желает вникать в проблемы заказчиков и пользователей, а менеджмент и заказчики не считают нужным информировать команду о многих аспектах решаемой задачи, считая это необязательным.
Симптомами наличия проблемы являются:
● заказчик считает, что команда не обязана знать о некоторых проблемах с привлечением пользователей, финансированием, проводимых презентациях и т.д., дело команды — писать код, а о вопросах бизнеса голова должна болеть совсем у других людей;
● в начале переговоров по проекту заказчик больше интересуется наличием формальных сертификатов вроде CMMI, чем знакомством с реальными членами команды, зачастую предпочитает общение только с менеджером и аналитиками;
● разработчики говорят: “Я хочу просто писать код, дайте мне четко поставленную задачу и я все сделаю. Про проблемы заказчика пусть болит голова у аналитика и менеджера” («телепаты в отпуске»);
● команда действует по принципу: делаем ровно то, что попросили, нам заплатят, а дальше нас не касается;
● менеджеры считают разработчиков оторванными от жизни существами, которых надо как-то развлекать и мотивировать, поскольку основная их работа — скука смертная и нужны специальные меры, чтобы они не закисли;
● сами разработчики считают основную работу скукой смертной и для сохранения мотивации занимаются сторонними опен-соурс проектами и мелкими стартапами, направленными не столько на заработок, сколько на получение отдушины от рутины;
● разработка проекта сопровождается тонной документов, но большинство рядовых сотрудников не в состоянии описать типичных пользователей продукта и никогда их не видели;
● общение между любыми представителями различных ролей напоминает поле боя;
● представитель любой роли может с ходу назвать чем именно он недоволен в работе менеджера и представителя любой другой роли в команде;
● в первую очередь каждый член команды может сформулировать чужую ответственность и только потом назвать свою;
● первой и основной задачей любого члена команды является прикрытие одного места сковородкой путем завышения оценок и спихивания ответственности за срыв на других.
Последствия для команды (в долгосрочной перспективе):
● мотивация снижена до критической отметки, никто не стремится сделать задачу как можно лучше;
● любые решения принимаются по принципу «лишь бы не влетело»;
● в особо тяжелых случаях принятие решений сопровождается несколькими этапами подписания бумаг;
● не приветствуется никакая инициатива по улучшению кода, архитектуры, внутренних процессов, инициатор в большинстве случаев получает вопрос «тебе что – больше всех надо?»;
● при первой же возможности наиболее перспективные члены команды меняют проект;
● единственной мотивацией становится денежная и карьерная, за достаточно долгий срок в команде могут собраться самые меркантильные конъюнктурщики либо те, кого не интересует ничего, кроме стабильной зарплаты и возможности уйти домой в 18:00.
Последствия для внутреннего менеджмента:
● нужны специальные меры по контролю за выполнением задач;
● за долгий срок команду покидают наиболее инициативные, те, кто остается, уже не вывозят;
● ответственность за срывы сроков лежит в основном на менеджере, мотивировать команду не допустить срыва можно только кнутом и пряником.
Последствия для менеджмента заказчика:
● заказчик многократно переплачивает за завышенные сроки и текучку кадров;
● качество продукта отличное только по бумагам, на деле код и архитектура могут быть ужасными, следовательно заказчик переплачивает за неудовлетворительное качество;
● если пользователи – широкий круг людей, добровольно выбирающих продукт, возможно уменьшение их числа по изложенным ниже причинам.
Последствия для конечных пользователей:
● нет прямого контакта с исполнителями и возможности быстро дать обратную связь;
● потребности удовлетворяются не полностью, чаще всего пользователей приходится специально обучать для использования продукта, поскольку он далек от их стандартных юскейсов;
● порядок и сроки выполнения заданий по добавлению нового функционала не соответствует потребностям пользователей.
Байки из жизни
Чтобы проиллюстрировать вышесказанное расскажу о некоторых проектах, над которыми мне приходилось работать в роли разработчика или менеджера.
Итак, фирма занимающаяся проектированием магистральных трубопроводов. Отделу разработки ПО дали задачу написать небольшую программу для отдела экологии. Исходные данные:
- o отдел, где все пишут десктопные приложения для автоматизации проектных и изыскательских работ на Borland C++ Builder;
- o только что устроившийся новичок, умеющий писать не слишком сложные десктопные приложения;
- o отдел экологии, выполняющий расчеты выбросов загрязняющих веществ при строительных работах при помощи набора экселевских таблиц.
Чуть подробнее об отделе:
Написана своя библиотека 2D-графики, в планах 3D (на дворе уже OpenGL и все такое). Написана своя хитрая структура хранения данных в памяти – этакая комбинация связанного списка и структуры с прямым доступом, т.е. массива. Для доступа используется очень низкоуровневый подход, никакой абстракции нет и в помине, сплошная адресная арифметика, причем не только в потрохах, но и на уровне API. Написан свой грид, который на вход получает адрес в памяти и все свои данные берет при помощи вычислений адресов относительно этого начала. Сдвиг где-то внутри в 1 байт рушит все. Наиболее эпично его название: “myGrid”.
Молодому бойцу – т.е. мне – предлагают использовать все это как составные части будущей программы на Builder, которая заменит текущий зоопарк экселевских расчетов. Заказчики – тетеньки от 45 и выше (начальники) и девочки около 25 (рядовые исполнители) – мыслят исключительно в категориях расчетов, каковые они воспринимают как не связанные между собой части и с их точки зрения разработка инкрементальна – расчеты повторяются один за одним и занимают примерно одинаковое время.
Около месяца я честно делала все на Builder, введенные через мега-грид данные попадали в мега-структуру в памяти, которая при сохранении на диск просто скидывалась как есть в бинарный файл и потом поднималась при чтении из файла в память как есть. Но я восстала. Заявила начальнику отдела, что задача откровенно предполагает использование базы данных – особенно учитывая требуемый многопользовательский режим. Еще месяц боев и я получила разрешение. Как раз собирались создавать корпоративную информационную систему (КИС) на Java+Oracle и я получила возможность делать систему как часть этой КИС.
Чем больше я погружалась в задачу, тем больше понимала, что расчеты мало того, что взаимосвязаны, так еще и данные для них в большинстве своем есть либо в различной нормативной и справочной литературе, либо поступают от сотрудников других отделов. Появилось понимание, какая система нужна экологам на самом деле и она мало походила на то, что они описали. Я торчала в их отделе, задавала вопросы, выходящие далеко за рамки данных мне расчетов, в итоге постепенно я вникла в механику работы всего института.
Я сделала то, что им на самом деле было нужно, гораздо больше того, что просили, но это заняло намного больше времени, чем предполагалось в начале. Полгода на первую версию с базовым для остальных расчетом и 2,5 года до полного завершения. За это время меня чуть не уволили за отсутствие видимого результата в первые 1-2 месяца (не помню уже точно) а также были существенно испорчены отношения с начальником отдела и тогдашним директором по ИТ, который был не из программистов, а из инженеров-проектировщиков.
Затем я начала обивать пороги начальства, пытаясь запустить процесс автоматизации и построения модели всего процесса изысканий и проектирования, поскольку на тот момент, как мне представлялось, я была практически единственным человеком, который целенаправленно изучал работу всех отделов института с точки зрения потоков входных и выходных данных на уровне цифровой модели проекта. Был еще отдел КИС, но они больше интересовались типами текстовых документов, а чертежи рассматривали как обычные бинарные файлы. Для меня же основной была модель, а все чертежи и текстовые документы – всего лишь отчетами, которые можно построить в любой момент, имея модель.
В итоге эта глобальная система так и не появилась по куче причин бюрократического и экономического характера, а я уволилась. К слову – кусочная автоматизация этого процесса имеется в других проектных институтах, а одна из ИТ-компаний зарабатывает на коммерческом продукте, который покрывал на момент последнего моего знания о нем (2010 год) процентов 60 того, что мне представлялось в 2006 году. Есть еще несколько продуктов, покрывающих изыскательские работы (геодезию, геологию и т.д.), использующих модель внутри, а чертежи в формате AutoCAD получающих как отчет. Но они, к сожалению, не имеют продолжения в проектировании трубопровода.
Вернемся к задаче. Вроде бы все было сделано правильно – пользователи получили продукт, который удовлетворил их потребности даже в большей степени, чем они могли рассчитывать. Но. Они получили его гораздо позже, чем хотели. Чем это для них обернулось? Большими потерями времени на рутину и как следствие — сверхурочной работой в течение лишнего года.
Какие ошибки были допущены:
1. Сбор требований посредством опросов начальства и изучения экселевских файлов.
2. Выбор малоизученной разработчиком на тот момент технологии разработки, что затянуло появление первой версии.
3. Попытка сделать первую версию системы сразу мега-универсальной.
Глобальной причиной всех этих ошибок было то, что я слишком увлеклась своими целями, забыв о целях заказчика. Я хотела сделать хорошую и универсальную систему, попутно изучив новые для меня технологии. А заказчик хотел всего лишь сократить время на выполнение расчетов и уходить домой вовремя.
Как должен был поступить идеальный сферический разработчик в вакууме:
1. Начать с изучения бизнес-домена путем полного погружения в работу отдела на некоторое время с целью изучения всех процессов изнутри вплоть до выполнения основных юскейсов рядового сотрудника отдела самостоятельно.
2. В течение недели, максимум двух, написать несколько макросов на Visual Basic, которые обеспечили бы использование результатов одних расчетов в качестве исходных данных для других, а так же оцифровать наиболее часто используемые справочники в эксель, что дало бы ускорение работы примерно на треть.
3. Имея рядом уже частично счастливого заказчика, спокойно разработать настоящую систему, уже понимая все юскейсы и основные риски, что дало бы ускорение процесса разработки тоже не менее, чем на треть.
На первый взгляд пример не вписывающийся в описанную выше проблему и симптоматику. На второй взгляд так оно и есть. Поскольку имело место быть наличие разработчика весьма мотивированного на изучение проблем заказчика и попытки их решить наилучшим возможным способом (не считая начальной ошибки с макросами, точнее с их отсутствием). Проблема в том, что все остальные, кто был вокруг, были совершенно не мотивированы на улучшение общей ситуации в компании. Вопрос, действительно ли мне больше всех надо я слышала регулярно. И в один прекрасный момент терпение лопнуло.
Каковы выводы из всей этой истории?
1. Пользователя надо знать в лицо. Причем не только менеджеру и бизнес-аналитикам, а всей команде.
2. В процессе создания функциональных и интерфейсных требований по максимуму должна участвовать вся команда.
Наличие этих условий даст команде возможность проявить творчество, а личное знакомство с пользователями и их задачами позволит наилучшим образом решать эти задачи. Когда пользователь абстрактен и безличен, никто не вкладывает душу в продукт для него.
Но что делать в случаях, когда нет доступа до реального пользователя?
На тему знакомства с пользователями и изучения их конкретных потребностей могу назвать еще два кейса. Буквально недавно мы сидели в офисе заказчика и имели возможность пообщаться с живыми пользователями будущей системы. И девочка-дизайнер интерфейсов несколько раз повторила фразу: «Ой, ну как же все-таки здорово, что можно вот так вот поговорить с пользователями! Обычно ведь не знаешь, кто это и как именно они будут в итоге пользоваться продуктом».
Собственно дело было в том, что пока мы общались с менеджментом заказчика, они предлагали сделать супер-универсальную аналитическую систему, которая бы позволяла показывать диаграммы и сводные данные по любым мыслимым разрезам и чем-то напоминала бы большой эксель, в котором сейчас пользователи и работают с таблицами графиками. Так сложилось что мы прилетели в Москву и собрались все вместе обсудить уже фактически окончательно проговоренные требования и подписать договор. Проблем было 2: с нашей стороны отсутствие четкого понимания сроков, поскольку некое универсальное нечто оценить сложнее, требования более расплывчаты, а со стороны команды, разрабатывающей интерфейс пользователя – ощущение, что такой универсальный интерфейс большинству пользователей будет не нужен и непонятен.
Мы с самого начала собирались предложить пригласить конечных пользователей и постоять с ними вместе у доски со стикерами и маркерами, провести story-mapping (опять же отсылаю к AgileCamp от Scrumtrek-а). Хоть это и не вышло, но тем не менее мы пригласили пользователей и с каждым из них поговорили, попытавшись понять, каковы его основные юскейсы и ожидания от использования системы. Итогом этого стало то, что супер-универсальность отмели и получили несколько четких юскейсов, которые закрыли 80% самого важного функционала. Все это позволит гораздо быстрее выпустить рабочий прототип, который уже принесет бизнесу пользу.
Похожая история произошла совсем недавно с другим нашим заказчиком. Он хороший программист, ставший с какого-то момента техническим директором. Поэтому он ставил нам по сути не бизнес-задачи, а предлагал конкретные архитектурные решения. Пытался добиться от нас опять же супер-универсальной и супер-модульной системы, которая делает все. Никаких конкретных кейсов из него толком вытащить не удавалось и конечных пользователей нам тоже не представили.
Полгода назад он был в Омске и мы провели полдня, составляя Lean canvas и делая Story-mapping. В итоге выбрали некий кейс для первого прототипа и все вроде бы шло практически идеально первые несколько итераций. Однако в какой-то момент вдруг поступило неожиданное требование, о котором не было даже намека на story-mapping-е, — создать некие справочники: организаций, геолокаций и т.д. Команда не задалась вопросом – зачем, а заказчик не счел нужным пояснить. А еще через 2 недели вдруг выяснилось, что у заказчика на носу срочное важное событие, для подготовки к которому ему требуется продукт. Он хотел заранее посадить пользователей наполнять систему данными, чтобы все успеть, но поскольку не предупредил об этом заранее, система не была готова к работе пользователей именно по тем юскейсам, которые им требовались в данный момент.
Какие выводы из этих двух историй:
1. Надо не только знать своих пользователей в лицо, но и получить с них информацию о самых главных вариантах использования системы, которые закрывают 80% их потребностей и должны быть реализованы в первую очередь.
2. Лучше ограничить влияние технического менеджмента со стороны заказчика настолько, насколько это возможно; настаивать на общении с людьми от бизнеса и конечными пользователями для наилучшего понимания целей создания продукта.
3. Нужно задавать вопросы заказчику относительно сроков назначенных демонстраций или других важных событиях, поскольку он может не подумать об этом сам. При этом важно понимать, что иногда дате наступления события, когда продукт будет использован для показа, должны предшествовать неделя-две для альфа-тестирования конечными пользователями.
Сразу после проектного института я работала в бездарно обанкротившейся впоследствии небольшой аутсорсинговой компании, в которой одно из первых заданий мы с менеджером совместными усилиями зафакапили. Система состояла из двух частей: записи видеопотока с камер наблюдения со стримингом в двух режимах – онлайн и в записи — и веб-админки для настройки параметров камер, систем хранения записанного видео и всевозможных нотификаций о событиях.
Менеджер знал, что у нас есть один большой технический риск – запись и стриминг видео. Были серьезные опасения, что за месяц разработчик не успеет изучить форматы основных камер и написать что-то удобоваримое для демонстрации заказчику возможности записи видео-потока. Поэтому он надеялся, что я быстро наклепаю админку, которой можно будет замылить глаз заказчику, он увлечется замечаниями и пожеланиями и на некоторое время забудет про видео, что даст второму разработчику время для маневра.
Однако, все эти соображения были лишь в голове у менеджера. Разработчики же видели конечный срок – 3 месяца – и особо не волновались. С заказчиком лично мы практически не общались, этим занимался менеджер. До нас же информация доносилась уже в виде распоряжений, с каковыми мы спорили и кое-где делали по-своему, оттягивая намеченные менеджером сроки. Мы наверняка бы уложились в общий срок (плюс-минус, конечно). Но мы не имели никакой работающей системы через обещанный месяц, поскольку и я, и второй разработчик преследовали свои цели, не шибко заботясь о заказчике – для нас он был всего лишь ником в скайпе да емэйлом. Поэтому я выбрала для разработки новый для меня фреймворк, чтобы убить двух зайцев сразу. Менеджер это дело не пресек, хотя и подозревал, что я не успею вместе с изучением уложиться в срок.
В итоге авторитет менеджера и компании в-целом в глазах заказчика сильно пошатнулся, начались перерывы в общении, отложился первый денежный транш.
Можно было бы сказать, что проблема в отсутствии правильного процесса разработки. Вот был бы дескать скрам и наступило бы счастье. Однако дело здесь все-таки не в самом процессе или его отсутствии – итерации с описанным скоупом с какими-никакими критериями приемки у нас были – дело в том, что мы не решали все вместе проблему заказчика. У меня абсолютно точно не болела голова о недополученных заказчиком прибылях за счет сдвига дедлайна.
Учитывая предыдущий опыт с экологами, я бы совершенно точно прониклась бы и стала думать в том направлении, в котором хотелось бы даже не менеджеру, а заказчику, поскольку менеджера все-таки больше интересовал вопрос прикрытия филейной части сковородкой, чем запуск прототипа с целью апробации и возможно даже коммерческого использования с ограничениями возможностей. Но – он не подал как следует, а я не проявила достаточного любопытства. Новый фреймворк с его техническими особенностями на тот момент интересовал меня гораздо больше. Его выбор тоже оказался неудачен в итоге, изучение отняло непозволительно много времени. Для этой задачи можно было выбрать один из динамических языков и фреймворк типа Django или Rails.
Какие выводы из этой истории?
1. Команда должна быть в курсе всех рисков и проблем бизнеса заказчика (зачем ему запуск и именно в эти сроки, какой именно функционал его устроит для прототипа).
2. Команда должна быть в курсе мотивов собственной компании (насколько проект важен для репутации, портфолио или финансового благополучия).
3. При обсуждении и выборе технических решений технический менеджмент должен в первую очередь руководствоваться проблемами бизнеса, а разработчикам разъяснять, что упражняться с новыми фреймворками на заказчиках негуманно. Чтобы разработчики тем не менее не теряли интерес к изучению нового, надо давать какие-то возможности применить новые технологии, но на своих внутренних проектах или давать время на open source разработки.
Это приведет к тому, что разработчики уже не смогут откровенно игнорировать и заказчика, и менеджера, поскольку будут чувствовать себя в какой-то степени в одной лодке и с тем, и с другим, понимая насколько успех проекта отразится и на них самих, поскольку успешный проект в портфолио – повод для гордости, не говоря уже о возможном улучшении финансового положения и компании, и конкретного разработчика.
За две недели до банкротства мелкого аутсорсера я перешла работать в филиал крупной аутсорсинговой компании.
Попала я туда интересно. Я пришла на собеседование просто из любопытства, для того, чтобы проверить свои скиллы на соответствие потребностям весьма уважаемой в городе компании. И меня совершенно очаровал интервьюер. Мы очень мило с ним поговорили о различных технических вопросах и я поняла, что он очень крут, у него можно поучиться многому. Он, как выяснилось, тоже меня оценил достаточно высоко, чтобы хедхантеры начали активно заманивать. На окончательное решение повлияло то, что мой интервьюер будет тимлидом команды разработки, в которую мне предстояло войти.
Я честно предупредила директора филиала и менеджера, что у меня есть собственная небольшая команда, которой я буду заниматься параллельно, получила согласие и стала вливаться в коллектив. Проектная команда в 45 человек, из которых разработчиков меньше трети меня немного удивила. Тестировщиков при этом было существенно больше, несколько выделенных аналитиков, у каждой команды свой лидер и над всеми – архитектор, менеджер проекта и менеджер программы.
Проект оказался долгожителем. Он существовал 30 лет на Фортране, затем в 2000-2001 году его переписали, сделав веб-проектом на Java+Oracle. При этом был полностью сохранен внешний вид интерфейса. Не столько потому, что к нему привыкли пользователи, сколько потому, что ни один разработчик до конца не понимал, в чем суть системы и что означают все эти экраны для ввода данных. За время существования проекта в компании на нем сменилось больше 100 разработчиков, сколько тестировщиков и аналитиков я не знаю. В итоге в той команде, в которую я попала, не было ни одного человека, который до конца бы понимал систему. Даже аналитики, которые бодро сыпали непонятными мне терминами, не могли ответить на большинство вопросов о целях и потребностях пользователей.
Все это привело к тому, что разработка велась методом наложения заплаток. Документы по системе, создаваемые аналитиками и тестировщиками, зачастую не соответствовали текущему состоянию кода, поскольку не у каждого разработчика хватало терпения их прочитать и выполнить все, что там написано. По некоторым юскейсам у заказчика и команды разработки были две различных картины одной и той же функциональности.
Именно на этом проекте я наблюдала большинство симптомов, озвученных мной выше. Мое желание разобраться в бизнес-домене вызывало недоумение. Ведь куда проще выполнять небольшую задачу, не вникая в то, что якобы ее не касается. Меня же беспокоило то, что система с точки зрения юзабилити была худшим примером, который мне когда-либо доводилось видеть. Время на обучение пользователя работе с ней было огромным. Пользователь вынужден был держать в голове огромное количество допустимых значений параметров и их сочетаний, поскольку система не выдавала никаких подсказок и даже валидация огромной формы часто выдавала просто надпись «Ошибка!», перегружая страницу с очисткой всех введенных данных, после чего несчастный пользователь вынужден был вводить все заново.
При этом в основном люди, которые работали на проекте, технически были очень компетентны, разбирались в огромном количестве тонкостей используемых и смежных технологий. Тем не менее, в глазах у многих я видела тоску. Компания, собравшая чуть ли не лучших разработчиков города, очень странно распоряжалась этими ресурсами. Были проекты, где небольшая команда разработки и буквально 1-2 тестировщика работали сверхурочно в постоянном режиме в то время как мы слонялись часто из угла в угол, не зная, чем себя занять, когда код отдавался в тестирование, а следующая итерация еще не начиналась. Но менеджеры программ на своих совещаниях изо всех сил держали своих людей, не отдавая их тем, кто в этом остро нуждался, поскольку понимали – обратно им могут их и не отдать, даже если будет надо. Очень многие разработчики, сидя внутри компании, зарабатывали на фрилансе, тратя на это основную часть рабочего дня.
Итогом стал уход нескольких достаточно инициативных сотрудников, которые в итоге заняли руководящие позиции в динамично развивающихся компаниях города либо уехали из него. Они были готовы реализовывать свои идеи и внутри предыдущей компании, но эти инициативы остались без внимания руководства, ибо на высоком уровне менеджмента проблемы конечных пользователей и даже внутренние проблемы команды разработки уже абсолютно не видны.
Для себя я сделала следующие выводы, которые в данном случае в большой степени спорны, поскольку найдется огромное количество людей, которые чувствуют себя совершенно комфортно в большой иерархически построенной структуре:
1. В подобной структуре масса людей, которые предпочитают не брать на себя ответственность и ценят «стабильность», становится критической. Это приводит к тому, что в те редкие моменты когда требуется с шашками наголо быстро забрейнштормить новый проект, никто не готов к такому виду деятельности. Поэтому в такие компании приходят проекты такие же скучные и долгоиграющие, как и те, которые уже находятся в разработке.
2. Если же проекты другого типа все-таки просачиваются, на них вроде бы поначалу все идет весело и интересно. Чаще всего разработчиками там становятся вновь прибывшие сотрудники либо пассионарии, сбежавшие с других проектов. Однако соседство полусонных команд с других проектов, которые постоянно собираются в коридорах поболтать или на кухне почаевничать, либо тех кто явно левачит в рабочее время очень быстро заставляет задуматься – а почему собственно я должен работать на износ, когда кругом куча народу получает зарплату практически ни за что и имеет кучу свободного времени. Это снижает мотивацию довольно быстро. Дальше людей начинает держать только зарплата и перспективы повышения в должности. Однако, очень многие в итоге все-таки уходят в стартапы, небольшие, но веселые команды или во фриланс.
3. Доля счастья на душу программистского населения в маленьких командах, не имеющих нескольких уровней иерархии управления, гораздо выше. Лично мне такие команды импонируют гораздо больше. Находиться среди людей с горящими глазами гораздо приятнее. Поэтому я бы очень не рекомендовала совмещать внутри одной компании упомянутые типы команд и проектов.
4. Скорость реакции на пожелания заказчика в маленьких командах выше, что повышает уровень счастья заказчика. Не всякий заказчик пока еще готов «рискнуть» и нанять маленького, но гордого аутсорсера. Однако же таковые на наше счастье находятся.
Формула любви счастья
Для меня и моего партнера она состоит из следующих компонентов:
• Разработка продукта, который задуман в первую очередь чтобы помочь пользователям решить какую-то очень важную проблему, а получение прибыли является побочным эффектом – просто такой полезный сервис не может не стать популярным. Продукт в идеале должен быть настолько интересным, чтобы им хотелось заниматься даже и бесплатно в свободное время. Поэтому возможность работать над ним за деньги – настоящее счастье для команды. В идеале продукт – свой собственный.
• Небольшая, но очень high level skill команда, в которой просто нет лишних людей. Каждый – энтузиаст и евангелист, помимо основной работы активно занимается саморазвитием, ведет блог просветительского характера, контрибутит в интересный open source проект либо делает свой собственный.
• Команда вникает в бизнес заказчика либо проблемы конечных пользователей настолько, что способна говорить с ними на одном языке и рассматривать продукт с точки зрения business value, адаптируя все процессы и технические решения под потребности бизнеса/пользователей.
• Заказчик настолько адекватен, что доверяет команде в выборе технических и процессных решений, позволяя ей самой решать, каким образом обеспечить потребности бизнеса в рамках обозначенного бюджета.
• Большое количество рутинных операций вроде деплоя и прогона разноплановых тестов автоматизированы настолько, что команда имеет достаточно времени для работы над действительно интересными и сложными вещами, требующими приложения мозга.
• У команды находится время проверять гипотезы на
Неплохая подборочка в стиле «Спасибо, кэп!». Собственно, для нас это пока некоторый идеал, к которому мы изо всех сил стремимся. Я ни в коем случае не претендую здесь на истину в последней инстанции. Существует масса успешных с точки зрения прибыли компаний, в которых нет ни одного из упомянутых пунктов. Либо огрызки от одного-двух из них. Но я хочу подчеркнуть, что я говорю не о максимизации прибыли, а совершенно о других вещах. Это момент в большой степени философский. Сами по себе деньги не особо нужны. Мешок денег на необитаемом острове бесполезен. Человеку нужно ощущение счастья, которое дается отнюдь не деньгами как таковыми.
Собственно цель моего выступления на конференциях и этой статьи — обсудить с коллегами аспект взаимодействия бизнеса и команды разработчиков, актуальность проблемы непонимания и недоверия в этом взаимодействии. Поэтому в первую очередь я готова задать вопрос читателям – актуально ли для вас то, о чем я говорила? Есть ли желание обсуждать эти темы подробнее?
Вопрос не праздный. Мы собираемся провести конференцию, построенную на несколько других принципах, чем те конференции, которые мы посещали последние пару лет. В частности: dump.it в Екатеринбурге, codefest в Новосибирске, devconf в Москве, agiledays и agilecamp. Конференция намечена на 29 сентября.
Идея состоит в том, чтобы разбить доклады на секции не по специализациям в команде: разработчики, тестировщики, дизайнеры, менеджеры, и не по используемым технологиям. Хочется объединить людей в секции по типам задач бизнеса, рассмотрев на каждой секции конкретные кейсы в комплексе. Людям, работающим в энтерпрайзе, на банки и прочие крупные компании не интересно слушать тех, у кого заказчиками являются стартаперы с ограниченным бюджетом, которым нужно быстро изготовить прототип для получения раунда инвестиций либо для проверки гипотезы и замера KPI. Хочется, чтобы люди делились между собой подходами к организации процессов разработки и выбору технических решений, исходя из потребностей решаемой задачи.
Спасибо всем, кто нашел время прочитать. Буду рада любым каверзным вопросам и советам по поводу затронутой темы.
