Производство счастья промышленными методами

    Моя статья будет представлять собой больше набор историй из жизни и некоторые выводы из них. Основная проблема, которая меня сейчас волнует: как сделать так, чтобы довольны были и заказчики, и разработчики, и прибыль была и карма цела. Конкретного окончательного рецепта у меня нет, есть несколько отрицательных примеров и намеченные цели, которыми хочется поделиться.
    Я занимаюсь разработкой с 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. В процессе создания функциональных и интерфейсных требований по максимуму должна участвовать вся команда.
    Наличие этих условий даст команде возможность проявить творчество, а личное знакомство с пользователями и их задачами позволит наилучшим образом решать эти задачи. Когда пользователь абстрактен и безличен, никто не вкладывает душу в продукт для него.
    Но что делать в случаях, когда нет доступа до реального пользователя? Можно завести резинового пользователя. Шутка, конечно. Для этого придуманы специальные практики разработки портретов пользователей. Команда создает реальный портрет человека, с именем, возрастом, профессией даже привычками, а так же страхами, которые могут возникнуть при пользовании продуктом, и какую пользу им этот продукт может принести. Возникают игровые моменты, шутки, внутренние мемы. Практика достаточно неплохо показывается на тренинге 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. Хочется, чтобы люди делились между собой подходами к организации процессов разработки и выбору технических решений, исходя из потребностей решаемой задачи.
    Спасибо всем, кто нашел время прочитать. Буду рада любым каверзным вопросам и советам по поводу затронутой темы.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 84

      –10
      Я всё прочитал и хотел бы узнать, где ещё можно посмотреть ваши фотографии?)
        +7
        Черт, я хотела закрыть тему девушкой с баяном :-)

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

          По поводу объема: вы не родственника Льва Толстого?)
          По поводу минусов: причина явно в половой дискриминации. Если бы вы были парнем, то результат был бы другим)
            +4
            Симпатичных девушек-программистов больше, чем вы думаете. У меня таковых двое работает.

            Изначально я хотела отделить то, что желательно прочитать, от баек. Но попросили убрать форматирование.

            Я привыкла к такой реакции :-) Не обращаю внимания.
              –10
              Ага, отлично) Тогда ваше фото и их тоже, будьте добры…

              Хмм… форматирование убрать, байки оставить?

              Вы привыкли быть белой вороной?) Моя знакомая говорит, что нужно быть клёвой белой вороной.
                +18
                Чувак, обычный инструментарий пикап-мастера на девушек-программистов не распространяются ;))
                  0
                  * не срабатывает т.е.
                    –15
                    AnnieOmsk — не девушка, а женщина в самом соку *облизнулся плотоядно*) Я уверен, что у неё достаточно опыта, чтобы почувствовать мой потенциал и ответить взаимностью)
                      +7
                      Эм, ну ок, желаю выдержать бенчмарк и все такое =))
                        +9
                        Меня терзают смутные сомнения, что вы идиот.

                        Один запрос в гугле выдал и фотографии, и семейный статус.

                        Так как я сегодня добрый, подготовил для вас небольшой перфоманс.
                        lmgtfy.com/?q=%D0%90%D0%BD%D0%BD%D0%B0+%D0%A2%D0%B0%D1%80%D0%B0%D1%81%D0%B5%D0%BD%D0%BA%D0%BE+%D0%BE%D0%BC%D1%81%D0%BA
                          0
                          Ого, спасибо, давненько не гуглила про себя. Увидела вот такое: moikrieg.ru/users/tarasenkoanna2/, посмеялась :-)
                            +4
                            Гугл меня подставил: секретарь омских «единороссов» — это не я! :-)
                              –5
                              Я взял большую часть минусов на себя — уже за это можно предоставить фото, Анна!;)
                                +2
                                По-моему гугл все отлично предоставляет :-)
                                  –4
                                  Ну, Анна, это не то… ) Это как спросить: «Ты меня любишь?», а в ответ услышать: «Посмотри в Гугле»)
                                    0
                                    Скоро даже вопроса задавать не надо будет, сразу гуглить — и все понятно :-)
                                      –6
                                      Это всё ваши милые отговорки, Аннушка, хороших людей нужно держать рядом с собой — давайте пойдём друг другу на встречу… )
                                        +7
                                        Всем чмоки в этом чате!
                                          +4
                                          Хаюшки, а сколько тебе лет? у меня есть собака Тошка
                                            0
                                            И тебе привет) Мне почти 25. А у меня есть кот Тошка)
                                            +3
                                            Хаюшки, а сколько тебе лет? у меня есть собака Тошка
                                –4
                                Практикуйтесь чаще в перфомансах — они выглядят у вас нелепо и смешно)
                                  +1
                                  А давайте не будем разводить личные оскорбления? Ей-богу оно того не стоит. Не портите каменты, пожалуйста :-)
                                  +8
                                  Я что, ошибся вкладкой и читаю Мамбу, а не Хабр? О_о
                                    –4
                                    Мне кажется, что на Мамбе люди «зажрались», пластиковые разговоры, конвейер.
                                      +3
                                      Вот и давайте не переносить методы общения оттуда сюда :-)
                                        –4
                                        Интересное предложение) Может быть обсудим его в аське или скайпе…?
                                        • НЛО прилетело и опубликовало эту надпись здесь
                        +14
                        Зашел в комментарии к статье, написанной девушкой.

                        Первый комментарий — просьба показать сиськи фотку.

                        Все, как положено.

                        От себя автору — спасибо, очень занимательно. Осилил половину, завтра дочитаю.
                        +4
                        Очень долгое чтиво, не так просто за раз осилить.
                        Всё вроде и понятно, но не всегда получается именно так, как должно было бы быть в идеале. В этом плане статья полезная для чтения всеми, кто связан с разработкой, чтобы оглядеться по сторонам, и оценить по-новому текущую ситуацию, всегда есть куда улучшаться.
                        Но самая главная мысль — разработка должна приносить удовольствие, это бесспорно.
                          +1
                          Очень интересно! Спасибо, что излили изложили личный опыт.

                          Вы, Анна, судя по всему, из неугомонных))

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

                          Как итог — увольнение, [другая контора,] «что-то свое» (конкуренция, демпинг… поиск счастья..)

                          Хотя, большинству (из нас))) работать «на дядю» — ноу проблем. Проблема — «невесть откуда» возникающее желание «бороться за здравый смысл» даже при хорошей зарплате.

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

                              Статья только про счастье, и мелкую разработку.
                                +1
                                Промышленные методы в разработке. Пока пользуемся кустарными :-)
                                  0
                                  См. мой ответ ниже
                                    0
                                    Писать лень, попроси как-нить раскритиковать при встрече )
                                      0
                                      А ты приходи в гости-то :-)
                                  0
                                  Простите, что влезу, но сколько времени по вашему должно занимать обсуждение всех инициатив? Допустим у меня команда разработки 20 человек, все такие инициативные с кучей идей и каждый ходит к PM и двигает свои идеи, некоторые из них противоречат идеям других разработчиков, или как обычно бывает, разработчики не владеют информацией в том же объёме, что ПМ или аналитик, просто потому, что у них нет столько времени на изучение проекта.
                                  Знаете, мне как руководителю, проще запретить инициативы от сотрудников, пусть даже мы на этом потеряем 5% скорости или качества, чем дам возможность вынести мозг человеку отвечающему за весь проект, потому что все эти «общие обсуждения», общее владение знаниями и т.д. может снизить производительность команды процентов на 30%.

                                  Я не говорю, что нужно всё запрещать и делать из людей безинициативных роботов, но нужно искать компромисс прежде всего.
                                    0
                                    Я не сказала, что наша мечта подходит всем и каждому. Да, в большой компании разработчику невозможно знать все тонкости бизнеса клиента. Этим занимается аналитик. Но:

                                    1) Бывают проекты, направленные на массового потребителя, каковым разработчик запросто может себя представить. Более того — лучше, если он будет это делать и смотреть на то, что делает команда, глазами пользователя — хотя бы иногда. А еще есть замечательный совет от Джоэля Спольски: «Ешьте свою собачью еду», т.е. пользуйтесь сами своим ПО, начиная с ранней альфы, и тогда большая часть багов и просто неудобных интерфейсных решений до пользователей не дойдет (к сожалению, точной ссылки сходу не нашлось, но эта статья есть в книге «Джоэль о программировании»).

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

                                    Резюмирую — не обязательно каждому знать все, но каждый должен знать достаточно, чтобы иметь ВНУТРЕННЮЮ мотивацию. Никакие танцы вокруг костра на тимбилдинге и крики «мы лучшие!!!» в толпу — не помогут. Конечно, это требует времени менеджера. И лучше его потратить на это, чем на бесполезные тимбилдинги для галочки.
                                      0
                                      1) Насколько я знаю, сотрудники MC используют такой подход в R&D подразделениях, но при этом продукты у них получаются как удачные, так и нет.

                                      2) Менеджер лапки не поднимает, а как раз общается со всеми. Я начальник этого менеджера и вижу на что он тратит время, обсуждая с джуниорами, почему их креативные идеи не подходят для текущего проекта. ИМХО, нужно чтобы джуниор шёл к сеньйору, сеньйор к архитектору и т.д. вверх. Чтобы менеджеру доходили только самые проверенные идеи. Да, я понимаю, вы сейчас начнёте говорить, что я создаю бюрократию, но порой для бизнеса в целом это выгоднее, чем тратить время на обсуждения и удовлетворение всех идей сотрудников.

                                      А никто не проводит бесполезные тимблиддинги для галочки. Никто не занимается криками, но при этом никто в кружке в 20 человек не обсуждает новые идеи, создавая горячие споры.
                                        0
                                        1) Ну это нормально, из 100 идей в R&D только одна может быть гениальной, но я имела в виду совсем другое.

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

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

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

                                        Вы не занимаетесь тимбилдингами для галочки — другие занимаются, таких масса, я своими глазами наблюдала и участвовала со стороны развлекаемых.
                                          0
                                          Сколько у вас человек сейчас команда?
                                            0
                                            17. Проектные команды по 2-4 человека.
                                      0
                                      Почему всех инициатив? Бредовые идеи должно быть стыдно выдвигать. Бредовость идей — как термометр профессионализма. Фломастером на стене)).

                                      Времени 3-5-10 минут ёмко (понимая, что менеджер персона занятая) и аргументированно высказаться в свободной речевой манере по пунктам:
                                      1. Какая проблема наблюдается (возможно невидимая не_совсем_специалисту_в_определенной_области менеджеру).
                                      2. Что создает эту проблему.
                                      3. Что можно/нужно сделать.

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

                                      Но проблемы обычно такие, что в команде 20+ человек, с менеджерами и руководителями менеджеров, возможно, и не существовали бы))
                                        0
                                        Примеры из моей практики.

                                        Есть предложение перенести сборку проекта на с Ant на Maven.
                                        Есть идея перенести проект с Hibernate на iBatis
                                        Есть мысль сменить аппликейшен сервер.

                                        Всё аргументированно, с + и -. И что делать ПМу? Если откажешься просто так, то обидятся. Если начнёшь доказывать, что в этом нет смысла, упрёшься в холивар, что ещё хуже и т.д.
                                          0
                                          На мой взгляд, в большой команде должно быть по взрослому и привито корпоративной культурой:

                                          Предлагаешь переход с А на Б — запили (на выходных, на коленке) две системы, нагрузи адекватно текущей специфике, сними характеристики, сравни, оформи отчетик/скриншот. Большой шанс отчету оказаться в кулуарах руководства в качестве козыря (@author Developenko, наш парень!) Никакого дара убеждения, все по специальности, по способностям. Получи за «рацуху» плюс в карму и, впоследствии, в карман. Никого не перепрыгнул, помог всем!
                                          А быть безучастным роботом или праздным холи-воином — не стайл.

                                          Не столько программистский мой опыт это подсказывает, сколько жизненный из других сфер деятельности.
                                            0
                                            Мы стараемся убеждать, что на проектах в продакшене менять движки можно только если есть очень-очень веские причины. И это все в команде понимают. Холивар и «я тут вчера статью прочитал, Maven лучше» — не аргумент. Недавно перевели, кстати, как раз — но по веским причинам. Переводили проект со Spring 2.5 на Spring 3.0, пришлось и на Maven заодно. Но тут вместе все просчитали, прикинули, согласовали с заказчиком (!) — и тогда уже сделали.
                                              0
                                              А кто решает веские это аргументы или нет? Как идёт обсуждение?
                                              Хотя да, если команда проекта 4 человека с этим проблем нет.
                                                0
                                                Пока что мы с Иваном главные технические и управленческие авторитеты, но это ненадолго. Ребята стремительно растут в техническом плане, мы со своей стороны стараемся поддерживать уровень осмысленности принимаемых ими решений. Мы по понятным причинам в техническом плане уже не растем и скоро они нас обгонят :-)

                                                Вообще — в каждой технологии должен быть признанный гуру. Причем ни в коем случае не менеджер. К этому гуру народ как раз-таки ходит за советом и уже одобренное решение несет менеджеру. Конечно, менеджеры должны авторитет гуру тоже признавать. Я видела такое на своей последней наемной работе, это работает.
                                                  0
                                                  Я как раз тоже сторонник такого подхода. Ещё важно, чтобы гуру понимал свою ответственность, т.е. если переход на новую среду сборки провалился или занял в 3 раза больше времени, чем планировалось, он будет нести всю ответственность за это решение и никак не сможет сказать — «команда это решила».

                                                  У нас на работе сейчас получается команды работают над проектами без менеджера по сути. Есть техлид, он же архитектор, и аналитик (несколько аналитиков). Результат к сожалению получается, мягко говоря, не очень. :(
                                                    0
                                                    Вообще — важнее всего человеческиий фактор. Как роли ни назови — без идейного лидера команда не работает.
                                                      0
                                                      Не согласен. Важнее всего команда, а не человеческий фактор.
                                                      Есть такая хорошая игра называется — «подводная лодка». Попробуйте поиграть с командой ;)
                                                        0
                                                        Сути возражения не поняла. Команда, а не человеческий фактор — что имелось в виду?
                                                          0
                                                          в том, что человеческий фактор не должен быть важнее всего.
                                                            0
                                                            Как будто команда состоит не из людей? Простите, не соглашусь с тем, что есть что-то важнее человека в нашем деле.
                                                              0
                                                              Команда состоит из людей, а люди из клеток. :)
                                                              Эх, вам бы hr`ом работать. =)
                                                              Я думаю на этом стоит закончить, вряд ли вы что-нибудь ещё сможете мне рассказать, а я вам донести :)
                                    +1
                                    Спасибо вам за вашу просветительскую деятельность. Ваш доклад приятно удивил на devconf'е.

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

                                    В контексте этого, у вас есть прекрасная идеализированная форма счастья, но нет пути и методов его достижения — только общее обозначение направления.
                                      0
                                      Направление — это уже полдела. Ну и сейчас счастье присутствует, только не со всеми заказчиками еще полная гармония. Надеюсь, что скоро позволим себе выбирать, как Злые марсиане, например. Это, кстати, для нас пример, что это все может сработать.
                                      +1
                                      Спасибо за пост!

                                      Когда дочитал до «Симптомами наличия проблемы являются:» прослезился, а после «Последствия для команды (в долгосрочной перспективе):» зарыдал и захотел обнять автора, посмотреть в глаза и проникновенно сказать: «Брат! (Сестра!) Хоть ты меня понимаешь!» )

                                      Самое интересное, что я работаю вовсе не в IT, но проблемы в плане менеджмента и организации работы прям один в один!

                                      Молодая, маленькая компания — энергия, драйв, общая цель. Все всех знают, со всеми общаются, все — одна семья. Рост компании — больше народу и начинаются проблемы с коммуникацией, когда мессадж от клиента, полученный где-то наверху или другим подразделением, доносится до какого-то «конечного» подразделения через несколько посредников, а значит с искажениями, привнесениями и иногда с совершенно другим смыслом. При этом эти искажения появляются не только в ходе путешествий информации от клиентов, но и во внутренней коммуникации. И вот уже подразделения не видят общей цели, не понимают, куда движется компания, к чему стремится, зачем. И все сентенции топ-менеджмента о целя, задачах, планах и перспективах начинают восприниматься как послания от инопланетян, оторванных от матушки земли. И в условиях потери этого смысла начинается поиск смысла нового — ведь как-то и зачем-то подразделению нужно существовать. И когда этот смысл находится, то как правило он входит в противоречия со смыслами соседних подразделений, которые также находились в собственных поисках. И начинаются ситуации, когда бухгалтерия (юристы, продавцы, производственники, логисты, вставьте свой вариант) считает себя основной структурой компании, а всех остальных лишь вредителями, которые только и занимаются тем, что пытаются помешать им работать. Соответственно любое межподразделенческое общение по серьезным вопросам — война (открытая или скрытая, когда «общаться с вами будем только через служебки»).

                                      Пока я ответ на вопрос «отчего так» нашел в книгах Адизеса про циклы развития компании и про стили управления. Там он очень четко объясняет, что на первых этапах нужен предпринимательский дух. Нужно придумать идею, которая продастся! Затем подключается «дух» производственный, чтобы «придуманную» предпринимателем идею воплотить в жизнь и обеспечить отгрузку продукции. А вот дальше, с ростом, как правило на сцену выходит «дух» административный, т. к. если на первых этапах компания не загнулась, то ее, разросшуюся, нужно как-то структурировать, чтобы ей можно было управлять. И вот тут-то, как мне кажется, на этом этапе, когда администрирование начинает играть важную роль, и теряется этот common cause, эта общая цель, а подразделения вместо нее получают регламенты взаимодействия, которые не дают ответ на вопрос «зачем». И этот ответ они начинают искать сами с результатами, о которых писал выше.
                                      Адизес еще говорит о «духе» интеграции, который на самом деле является чуть ли не важнейшим и который как раз может решить эту проблему, но я пока не встречал его нигде в своей практике и у меня пока есть сомнения в том, что это осуществимо. Даже в маленькой компании из менее, чем 20 человек, где я работал, я столкнулся с тем, что руководство уже «отделено» от коллектива и нет этой интеграции. Про многотысячные корпорации я уж и не говорю

                                      В этом плане очень интересен пример Valve с недавно облетевшей сеть книгой нового сотрудника Valve. На мой взгляд, это вот как раз пример этого самого «духа» интеграции.
                                      Я сейчас еще хочу найти подобные же документы других компаний (Apple? Google?), чтобы посмотреть, а как там!

                                      Вот такие вот мысли и еще раз спасибо за пост! )
                                        +1
                                        Чтобы не попасть в кризис роста, надо не допускать роста :-) Есть замечательная книга От хорошего к великому, в которой описаны различные стратегии увеличения прибыли компании. Одна из них — повышение прибыли в пересчете на одного сотрудника. Мы выбрали именно ее. В этих условиях бурный рост необязателен.

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

                                        Соответственно, чтобы увеличивать прибыль на сотрудника, надо иметь очень прокачанную и самомотивированную команду (очень рекомендую доклад Дмитрия Лобасева про«внутреннюю морковку», смеялись до слез), а так же автоматизировать все, что только можно, чтобы сократить издержки на разработку.

                                        Тут уже звучало, что метод не промышленный — ну может и так, а на мой взгляд для аутсорсеров — самое то.
                                          0
                                          Эх, вот только проблема в том, что компания уже выбрал экстенсивный путь и теперь с этим нужно что-то делать! )

                                          За ссылки спасибо.
                                            0
                                            Можно пытаться устроить в рамках большой компании небольшие проектные команды, полностью автономные. Которым выделяется бюджет и они делают проект полностью своими силами. Внутреннее предпринимательство по сути.

                                            Но тут нужна огромная адекватность руководства.
                                            0
                                            Осилил текст. Благодарю! Многое срезонировало. Однако большую часть жизни я выступаю как сольный разработчик, работая напрямую с заказчиком, так сказать лицом к лицу. Всегда пристегиваюсь к профильному специалисту, работу которого предстоит автоматизировать. Как правило в первой фазе разработки добиться внятного формулирования задачи зачастую не удается. Люди банально не привыкли выражать словами то, что делают руками практически на автомате.

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

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

                                            Очень быстро надоело клепать интерфейсы в ручном режиме, поэтому в 2003 году, потратив на это, в параллели, пару месяцев, написал небольшой фреймворк, поверх стандартного грида. В результате 90% пользовательских интерфейсов генерились уже на лету, основываясь на структуре БД и связей, которые просто прописывались в конфиге. Соответственно при каких-либо модификациях структур данных/связей нужно было обновить конфиг, и о чудо, большинство интерфейсов тут же подстраивались под новые данные. Очевидно, что все, что только возможно, выносилось в справочники, и подключалось методом подстановки через ID, что освобождало от массы проблем. Целостность справочником приходилось периодически мониторить, т.к. пользователи норовили, по лени и невнимательности, дублировать записи, с некоторыми грамматическим отличиями в написании.

                                            Воспроизвести полный цикл на веб-платфоре мне пока не удалось, в виду разнообразного зоопарка технологий, применяемых для реализации веб-приложений. Но тот же jqGrid, да небольшой самописный фреймворк и тут спасает неплохо.

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

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

                                            Доводилось даже в некоторых задачах синхронизировать и завязывать на себя работу до 4-5 разных отделов, предварительно заручившись полной поддержкой «самого главного». Отделы выдавали данные из разных сфер и областей, которые необходимо было проинтегрировать и получить конечный срез.

                                            Путём таких «финтов ушами» мы получали уникальную прозрачность бизнес-процессов в организации. К сожалению за последний год в той организации сменилось руководство. Новое наработками заморачиваться не стало, в результате заменив все разработки 1С и иже с ими, которые до конца настроить не смогли. В результате весь достигнутый прогресс, вся прозрачность и контроль процессов чуть менее чем полностью утрачены. Зато в мутной водице удобно ловить рыбку. Да, вы правильно догадались, контору захватили рейдеры. То, что трепетно и ответственно выстраивалось больше десятилетия, было уничтожено за несколько месяцев на корню. Увы.
                                              0
                                              Да-да-да, сидеть рядом с пользователем и научиться делать то, что делает он, а потом понять как это автоматизировать.

                                              Меня первый раз пробило, когда мне тетеньки-экологи показали, как они делают расчет в экселе, а потом на моей форме :-) Разница во времени — 3-5 раз. Не в мою пользу. В итоге я им сделала поведение формы в браузере с точки зрения клавиш — как в экселе, чтобы никакой мыши, переход по Enter и т.д. В итоге они смогли использовать свою моторную память и были довольны.
                                                +1
                                                В моём случае они заполняли вручную огромные тетради, которые называются «полотенца». Причем проверяли и перепроверяли расчеты по много раз, т.к. неизбежны ошибки. Все это происходило при помощи калькулятора, который нередко «затуплял». В общем 2 недели в месяце им было ну очень весело.

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

                                                Сначала они проверяли программу по тетради, через пару месяцев уже проверяли тетрадь по программе. Через 4 или 5 месяцев тетради отложили в сторону и заменили распечатками из программы. Программа отработала как часики с 2003-2004 по 2012, пока ей на смену не пришла 1С.

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

                                                Это пример только одной программы. Их было много. :)

                                                Последние пару-тройку лет от Клиппера я уже отказался, в силу его весьма скудного инструментария, по отношению к тому же PHP/MySQL. Некоторые программы до сих пор работают, а я уже год как оттуда уволился.
                                                  +2
                                                  Мой модуль для экологов тоже до сих пор работает, никто им не занимается. Я уходила в декрет в 2006-м, с тех пор я его не правила. У них очень медленно меняются процессы, поэтому изменений софта могут не требовать годами :-)

                                                  А еще в 2006-м их начальница мне сказала: хватит все автоматизировать, а то вместо отдела оставят одного человека, уймись!
                                                    0
                                                    Тоже верно. Правда наших бухгалтеров не сокращали, а просто навалили на них еще кучу работы. Если они до автоматизации занимались десятком задач, то после парой-тройкой, помельче.
                                              0
                                              Скажите, а как вы боритесь с текучкой кадров?
                                              Если в один месяц у вас по разным причинам отвалится 4 человека? 1 в отпуске, 1 болеет, 2 уволились?
                                              Для большой компании 4 человека будут проблемой, но не смертельной, а для команды в 5 человек это может привести к закрытию бизнеса.
                                                0
                                                Ну вообще. отпуска неожиданными бывают редко. Планируем так, чтобы вся проектная команда не уходила в отпуск одновременно. С этой целью, например, супругов стараюсь по разным командам разводить, но не всегда получается :-)

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

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

                                                  p.s. Я видел пример, когда из «команды» в 7 человек, за год ушли 4, хотя все пьянки, гулянки и т.д. были проводили вместе. Уходили люди по разным причинам, но с фактами не поспоришь. Что сейчас делает ПМ, я не знаю. Но, я бы, наверное, ушёл бы тоже оттуда на его месте.
                                                    0
                                                    Пока что за 2 года с проблемой не столкнулись. Все, кто ушел, либо не подходили по духу, либо сильно заранее предупреждали и уходили, никого не подставляя. Последние, кстати, периодически заходят в гости, кто в городе, и остаются в общих чатах команды (кроме проектных). Дают советы по вопросам своей компетенции всем сотрудникам, даже тем, с кем не успели познакомиться лично.

                                                    Конечно, я видела и другие случаи, но чаще всего, там были все-таки внутренние проблемы того или иного сорта.

                                                    Риск есть для меня в двух случаях: мы накосячим или кто-то резко начнет бомбардировать ребят с предложением зарплаты в 2-3 раза выше. Со вторым мы вряд ли сможем что-либо сделать, кроме повышения зарплат. Это по сути форс-мажор, как нынче со «Сбербанк-технологиями» в Java-мире.

                                                    Скажу совсем крамольную мысль — мы не расстроимся, если все наши ребята разойдутся по крутым конторам и от нашей ничего не останется. Мы будем считать свою миссию выполненной в каком-то смысле, да и сами не пропадем :-)
                                                      0
                                                      Я правильно понял ответ: мы никак не работаем с этими рисками?
                                                      И второй момент, если ребята разойдутся по крутым конторам, и проект свалится по всем срокам — это нормально?
                                                        +1
                                                        А как вы оцениваете вероятность — все остальные риски недовольной команды vs гипотетическая возможность появления в Омске конторы с зарплатами x2?
                                                          0
                                                          Ребята не разойдутся, бросив проект. Не те ребята :-)
                                                            0
                                                            Да, я никак не работаю с этими рисками в том смысле, который имеете в виду Вы. Я не рисую диаграммы и не оцениваю вероятности. И не потому, что не знаю о том, что это делают другие компании. Я читала книгу Ди Марко и Листера Вальсируя с медведями, на AgileCamp с удовольствием принимала участие в тренинге от хабраюзера blv, и т.д.

                                                            Я осознанно приняла решение, что в наших условиях все это излишне. Все, что я могу сделать, это не покупать лексусы за счет недоплаченных зарплат и быть своей команде другом, а не цербером. Пока что это работает. К сожалению, метод слишком индивидуален и в качестве общего рецепта не годится (хотя человееское отношение к команде вряд ли будет вредным советом :-)).
                                                0
                                                Спасибо! Это лучшее за последнее время на хабре =)

                                                Действительно, некоторые ситуации один в один похожи на случившиеся со мной или со знакомыми. Многое из написанного знакомо. По поводу некоторых капитанских вещей, я не устаю повторять себе «Повторение — мать ученья». Всегда во всем давно известном можно найти что-то новое.
                                                  +4
                                                  Текст интересный и большой, но сложно читать. Было бы круто видеть логические разделения, подзаголовки.
                                                    +1
                                                    Вот, кстати, да — текст неструктурированный. Осиливается тяжело.
                                                      0
                                                      Поторопилась, да. На конференции он был разбит по слайдам, там этого не чувствовалось
                                                        0
                                                        А на слайдшере есть? Я бы еще раз ознакомился, но уже в слайдах!
                                                  0
                                                  Вторая половина статьи читается как исторический роман. Что-то типа «как мы зафакапили всё, что можно» :-)

                                                  Я только не понял, к настоящему моменту что уже есть, кроме принципов счастья и пожелания команды из высокоуровневых коллег?
                                                    0
                                                    Команда есть, которую прокачиваем технически всеми возможными способами и интересные проекты, на которых стараемся работать по этой схеме. Как-то так :-)
                                                      +1
                                                      Иногда рассказ о факапах полезнее, чем об успехах. Вдруг кто-то узнает себя где-то на начальной стадии и избежит этих ошибок.

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

                                                    Самое читаемое