или
как наладить работу маленькой веб команды при позаказной разработке
TL;DR;
Многие успешные компании постепенно избавляются от балласта «лишних» вертикально-ориентированных отделов, должностных «прослоек» между СЕО и рядовыми сотрудниками компаний. Это позволяет им более эффективно руководить своими активами, оперативнее реагировать на рыночные изменения и не терять драгоценное время, стоимость которого растет день ото дня. Неудивительно, что компании, идущие в ногу со временем, постепенно приходят к холакратии.
Технологические компании постоянно внедряют инновации не только для своих продуктов, но и для внутренних процессов, позволяющих им оставаться лидерами на своем рынке. Именно поэтому такие игроки как Zappos, Medium, GitHub и многие другие предпочитают такое явление управленческого строя как «холакратия», подразумевающее управление компанией без иерархий и менеджеров.
Вместо традиционных «вертикальных» иерархических отношений в управленческой структуре компании, наличия «контролирующего» штата сотрудников и намертво закрепленных за отдельными сотрудниками должностей холакратия предлагает:
- отсутствие вертикального управления;
- любой сотрудник может оказывать влияние на принятие решений;
- управленческие роли выполняются параллельно с функциональными ролями;
- объединение сотрудников для решения задачи;
- роли в команде, которых у сотрудников может быть несколько в зависимости от компетенций;/li>
Подробнее: Холакратия убивает корпоративную иерархию
У американской ИТ-компании Valve: в ней нет боссов и менеджеров, нет «жесточайших распоряжений» и «пятилеток», каждый работник является product owner’ом и работает в прямом смысле на самого себя.
Штатный экономист Янис Варуфакис так описывает свою компанию:
Многие просвещенные корпорации поют и пляшут по поводу того, что они готовы позволить сотрудниками тратить 10 и даже 20% рабочего времени на свои собственные проекты. Отличие Valve в том, что ее сотрудники тратят 100% рабочего времени на свои собственные проекты».
Делаю историю короче — в Valve полностью отсутствует командная система. Управление здесь осуществляется не через принуждение и регулирование вышестоящей кастой управленцев, а полностью на базе «спонтанного порядка»
Подробнее: Valve: культ Т-образных людей
Люди, родители которых гордились одной записью в трудовой книжке, отрицают график с 9 до 18 и гарантированную зарплату. Они предпочитают свободу стабильности. Офисные работники бросают успешную карьеру и уезжают на Гоа, учителя становятся частными репетиторами, а сварщики — «мужьями на час». Ситуацию не спасают внушительные бонусы, привлекательный соцпакет, реорганизация и тренинги по тимбилдингу. Удаленная работа и гибкий график все чаще встречаются в описаниях вакансий. Только обещанием свободы можно заманить хороших специалистов в офис.
Но руководители не готовы отказаться от тотального контроля.
Фредерик Лалу (Frederic Laloux), бывший партнер компании «Маккинзи», в книге «Открывая организации будущего» (Reinventing Organizations) нашел ответ на вопрос, чего хочет работник XXI века. Эволюция организаций Лалу изучил компании по всему миру и пришел к выводу, что прежние организационные модели не отвечают потребностям современных людей.
подробнее: Организации будущего – как создать компанию в которой захотят работать даже фрилансеры
Цитаты из Открывая организации будущего
Говорят
Согласно исследованию компании Standish Group, затраты на ИТ-проект в среднем превышают отведенный под него бюджет на 43%. … только 29% ИТ-проектов были выполнены в срок и в рамках бюджета, 53% проектов не были сделаны в срок или не уложились в бюджет, а 18% просто провалились.
Как не провалить ИТ-проект и остаться в рамках бюджета
14 наиболее распространенных ошибок в области управления проектами
6 вопросов, которые спасут проект
7 причин провала вашего интернет-проекта
А зачем это владельцам бизнесов?
а затем что распределение затрат на управление между членами команды, и между командой и заказчиком – снижает себестоимость.
Трансакционые издержки
По-настоящему фундаментальное значение трансакционных издержек для организации было открыто в прошлом веке американским экономистом Рональдом Коузом.
… В рамках своих исследований Р.Коуз пытался ответить на простой вопрос: «Если сотрудники фирмы способны самостоятельно заключать и реализовывать коммерческие сделки, то почему они не делают этого как отдельные предприниматели? Почему вообще фирмы существуют?»
… Сформулированная теорема отражает предельный случай, который в реальной экономике не встречается. Равенство трансакционных издержек нулю означало бы невероятные способности людей:
- все всё знают и новое узнают мгновенно и однозначно, все друг друга понимают идеально, то есть даже слова не нужны;
- у всех со всеми всегда согласованы ожидания и интересы, при изменении условий согласование происходит мгновенно, а любое оппортунистическое поведение исключено;
- для каждого товара или ресурса всегда найдется взаимозаменяемый.
Мир с нулевыми трансакционными издержками — это мир без «трения в отношениях», «экономика сверхпроводимости или сверхтекучести». Теорема Коуза — это «ноль по Кельвину» в экономике.
…
Теорема позволила Р. Коузу ответить на вопрос: «Почему фирмы вообще существуют и бывают устойчивы продолжительное время?» Ответ оказался связан с трансакционными издержками: «Фирма существует и устойчива, если ее внутрифирменные трансакционные издержки меньше, чем внешние рыночные». Применяя физическую аналогию с трением, можно сказать, что «потоки ресурсов (активов) текут туда, где меньше вязкость (внутреннее трение)».
Переводя этот вывод Р. Коуза на обыденный язык предпринимателя, получим следующее утверждение: «Если со мной проще договариваться, то договариваться будут со мной». Если я по отношению к другим умею снижать свои трансакционные издержки, то я получаю преимущества, приводящие к естественному перераспределению прав в мою пользу. Я не отнимаю права у других — они их сами отдают, потому что это выгодно.
В поисках эффективности ИТ
Сколько реально вы платите работнику
Мало кто из нанимателей умеет правильно вычислить стоимость сотрудника. Обычно упускают из виду несколько очень важных цифр. Эту ошибку делают все аудиторы, бизнес-магистры и прочие дипломированные экономисты, каких я только видел. Ее повторяют все книги по менеджменту, которые мне приходилось читать. … Вот как они считают: заработная плата + налоги + бонусы + накладные расходы.
Предположим, вы платите Мэри $12 в час.
Подробнее Как узнать ПОДЛИННУЮ стоимость сотрудника?
Но в действительности и в итоге цена, в которую вам обойдется ваша сотрудница, достигнет $36,22 в час.
Вы и понятия не имели, что на самом деле столько платите Мэри, правда?
О том и речь. Бьюсь об заклад, вы требовали бы от Мэри больше и управляли бы ею иначе, если бы знали. Теперь вы знаете.
Сколько стоит час работы программиста
Главный наш вывод состоит в следующем: оценивать стоимость услуги нужно с позиций ее ценности для заказчика, а не себестоимости. Кроме того, покупая услугу, надо быть готовым к тому, что зависимость качества от цены имеет нелинейный характер. То есть, небольшое повышение качества услуги может привести к серьезному повышению ее стоимости. А дальше уже дело каждого конкретного Заказчика — решить, нужно ли ему это качество, или он готов повысить свои будущие риски ради экономии.
Сколько стоит час работы программиста?
А зачем это самой команде?
«мы же и так делаем сайты, и вполне успешно, и удовлетворены сложившимися процессами и взаимодействием»
«Не нужно пытаться изменить жизнь, она и так изменится.
Вопрос только – а в желаемую ли сторону?»
Меняются технологии(Отмотаем на 10 лет — на дворе 2006 год.), появляются конкуренты, или спад спроса в связи с проблемами в экономике. Да и просто – захочется тратить на работу меньше времени, а чтобы доход остался на том же уровне.
И как нередко бывает – 5 успешных проектов сами по себе не застраховывают от провального 6го.
И все упирается в эффективность, в продуктивность работы. и в ее контролируемость. в – скорость и точность разработки.
Я же считаю достаточными следующие аргументы
- внятные процессы самоуправления нужны для того чтобы брать более сложные (и интересные и денежные) проекты, когда обычные методы коммуникации не годятся.
- внятные, открытые процессы позволяют заказчику почувствовать удовольствие от работы с командой. А удовольствие заказчика «многого стоит»
- формализованные правила, регламенты позволяют легко привлекать на какие-то части работ субподрядчиков, фрилансеров с нужной компетенцией, без значительного увеличения рисков и затрат времени на управление ними, без необходимости кому-то из команды становится полновесным ПиэМом
- в маленькой команде все скорее универсалы чем специалисты. в пределе мифические full stack разработчики, а время для переключения головного мозга с задачи на задачу никто не отменял. Легковесные процессы, регламенты позволяют разгрузить голову, а не держать в ней чек-листы, и прочие напряжения в виде – «ой, надо не забыть после деплоя, зайти в админку и выставить флаг Х»
… можно делать что угодно и как угодно. Главное, чтобы в основе работы лежал принцип.
Принцип может быть любым (много разных принципов — тоже хорошо). Например, всегда выкидывать первый показанный эскиз. Или писать все заголовки без прилагательных. Или оканчивать все названия товаров на «-ус». Или красить боковинку оранжевым. Или что угодно еще.
Наличие принципа — одна из самых удобных форм ограничения. А без ограничений не бывает творческого процесса.
Нет ничего хуже и бессмысленней работы без принципа.
§ 176. Принципы
Бирюзовый PMbook
Важно
- предлагаемые рецепты являются не только субъективными предпочтениями и вряд ли годятся для большой команды, а и не будут работать и в маленькой команде, если ее члены реактивны, и делают свою работу супер-хорошо, но по принципу – я свое сделал – а что там дальше меня не интересует, это НЕ моя зона ответственности. см местами спорную
Где ответственность, или кто такой Senior Software Engineer - исключения бывают из всякого житейского правила, а тем более в такой неопределенной, трудноформализуемой деятельности как создание ПО. Поэтому я о них не упоминаю вообще, чтобы не увеличивать объем текстов в разы (описание исключений обычно превышает размер основной части). т.е. категоричность тезисов – стилистическая, а не семантическая.
«Избегая поражений – достигнешь победы автоматически»
Бирюзовый PMbook
Руководства, регламенты
Описания, рекомендации по выбору инструментов
Описания, рекомендации по выбору инструментов
Присказки, сентенции
Статьи
Статья написана по опыту запуска больших (400+ часов) и очень больших (1200-4000 часов) проектов.
Начнем с вывода.
- При создании большого веб-проекта нужно выбрать самое важное и запустить его как можно быстрее, не тратя деньги и время на «доведение до идеала».
- После запуска мы изучаем реакцию, корректируем план и приступаем к следующей итерации.
Это дает возможность быстро запуститься и перестраиваться под требования рынка. - Медлительные перфекционисты проигрывают.