)

2021-04-28 09:30:57 Итеративный рефакторинг

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

Я уверен что от технического долга избавиться невозможно, он всегда будет присутствовать на любом проекте. Борьба с ним - процесс итеративный. 
 
Вместо того, чтобы остановить разработку и все переписывать, стоит закладывать в оценку сроков на выполнение каждой новой задачи дополнительных 2-3 дня на рефакторинг. 
 
Вместо того, чтобы тратить на таску 3 дня, на нее уйдет неделя, но в процессе можно оптимизировать логику, которую задевает эта задача. 
 
При работе с уже написанным кодом стоит придерживаться правила Бойскаута - оставлять код чище, чем он был до тебя.
 
Например, поступила новая задача расширить функционал создания пользователя. Это отличная возможность переписать слой работы с данными для сущности пользователя, вынести из нее бизнес-логику в сервис и отделить ее от транспортного уровня. 
 
В процессе можно задекомпозировать уже существующие методы, переименовать непонятные переменные и переписать участки кода с несколькими уровнями вложенности.

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

Дополнительно, если старый код еще не покрыт тестами, то у тебя появилась замечательная возможность это исправить.
 
Каждое такое изменение будет незначительно улучшать качество проекта, на 1% в единицу времени.

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

2021-04-21 09:30:59 ​​Дизайн системы, технический долг и скорость разработки

Месяц назад я устроился разработчиком в стартап от крупной компании из США, которая создает программные продукты для большого Enterprise. Проект находиться на стадии MVP, старого legacy нет. В команде бэкенда только два программиста.
 
Зачастую на таких проектах приятно работать. Впереди тебя ждет разработка новых фич вместо поддержки старого функционала и постоянного фиксинга багов.
 
Первую неделю я изучал кодовую базу и закрыл скоуп задач по второстепенной логике. Откровенно говоря, я остался не в восторге от качества кода и архитектуры проекта. 
 
Бизнес-логика намешана внутри транспортного слоя и репозитория, из-за чего покрывать тестами подобное решение очень сложно. Подавляющая часть переменных, функций и методов имеют непонятные и неконсистентные именования. 
 
Архитектуре характерна сильная связность. Изменение одного метода влечет за собой непредсказуемые последствия на корректность работы абсолютно разных компонентов.
 
Большинство методов имеют слабую декомпозицию, за счет чего они очень длинные и сложны к восприятию. По коду часто встречаются цепочки из условных операторов и циклов с несколькими уровнями вложенности. Можно встретить “не чистые” функции, которые по выполнению оставляют побочные эффекты, о которых ты даже не догадываешься.
 
Все вышеперечисленные проблемы несут за собой ряд последствий. Изучать логику проекта сложно, у новых разработчиков уходит на старте много времени. Поддерживать и расширять подобный код становиться трудно, из-за чего проект со временем начинает обрастать костылями. С каждой новой фичей тех. долг растет, а сложность кодовой базы возрастает экспоненциально. 
 
На вторую неделю я взял в работу задачу по интеграции со сторонним продуктом, который входит в экосистему решений компании. Потратив 2 дня на изучение бизнес требований, API спецификации, общение со специалистами со стороны заказчика и проектирования технического решения я приступил к разработке. 
 
Данная задача подразумевает расширение существующего функционала. Однако углубившись в уже реализованную логику, я не смог ничего добавлять, пока не отрефакторил 80% написанного кода.
 
На задачу, которую можно выполнить за 3-4 дня, у меня ушло полторы недели. Помимо реализации бизнес логики мне пришлось переписать огромное количество кода и убедиться, что вся остальная логика системы при этом не поломалась. Без надлежащего покрытия тестами это тоже не простая задача.
 
Многие программисты и менеджеры убеждены, что в условиях сжатых сроков, писать плохой код полный костылей экономит время.

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

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

Главное правильно преподносить информацию, а если вы недавно пришли в команду, помните, что сначала нужно заработать карму. Відкрити / Коментувати

2021-04-14 09:30:28 Я middle разработчик, что дальше?
 
Если ты самостоятельно решаешь поставленные задачи, предлагаешь варианты реализации новых фич, умеешь оптимизировать и рефакторить код и уверенно владеешь своим техническим стеком - тебя с уверенностью можно назвать мидлом. 
 
Скорее всего у тебя несколько лет опыта работы в индустрии и пару проектов за спиной. На этом этапе многие задумываются о том, куда двигаться дальше и в какую сторону стоит развиваться. 
 
Вопрос построения карьеры достаточно интересный. Каждый обладает собственными взглядами, целями, амбициями, жизненными ценностями и областью интересов. У обычного разработчика есть много вариантов для дальнейшего развития, а выбор конкретного пути сугубо индивидуален.
 
Сейчас мне 20, скоро будет 21. В 16 лет я работал веб-разработчиком на небольшой веб-студии во время летних каникул. В 17 переехал в Киев и устроился фулстеком. После этого было еще две компании, где я получил бесценный практический опыт в backend разработке.
 
Помимо основной работы я немного фрилансил, делал “леваки” с друзьями и небольшие пет-проекты.

Недавно я начал работать на своем 5-ом рабочем месте как senior инженер, а параллельно занимаюсь развитием собственного SaaS-продукта, о котором расскажу чуть позже. 
 
Я достаточно молод и мне еще много чего предстоит повидать. Несмотря на это, последний год я много задумываюсь о построении собственной карьеры и жизни в целом. Столкнувшись с вопросом “куда можно развиваться из позиции middle?” я проанализировал все доступные опции, а результатами размышлений хочу поделиться с вами.
 
Для меня работа - это инструмент, который дает возможность хорошо зарабатывать, содержать себя и своих близких, изучать практики разработки современных приложений на реальных проектах и развивать свои навыки работы в команде. Ну и помимо всего прочего, я кайфую от решения сложных задач и состояние потока во время кодинга.
 
Я не привязываюсь к рабочему месту. Когда я чувствую что мне стало скучно, прекратился мой профессиональный рост или у меня есть варианты поинтересней - я ухожу.
 
Поэтому я считаю, первое, что стоит сделать при планировании своей карьеры - определиться зачем ты вообще занимаешься разработкой и к чему стремишься. 
 
Возможно на этом этапе окажется что для тебя это просто способ заработать, но ты не кайфуешь от своей работы, или у тебя есть другие интересы, которые ты игнорируешь из-за уже протоптанного пути. Возможно ты поймешь что хочешь чего-то совсем другого. И это отлично. Я уверен что нужно экспериментировать и не привязываться к чему-то одному.
 
Также важно держать в голове, что твоя карьера - это не воля случая. Ты в состоянии строить свою жизнь и выбирать путь развития. Твои решения непосредственно влияют на твой путь.
 
Когда ты поймешь себя и чего ты вообще хочешь от жизни, выбрать дальнейшее направление будет гораздо легче.
 
Как по мне, у мидла есть 3 основных варианта профессионального роста: 
1) Развивать техническую экспертизу вглубь, становиться senior`ом / архитектором / тех. лидом.
2) Развивать управленческие навыки, становиться тим лидом / PM / CTO и тд.
3) Развиваться в создании продуктов и бизнесе. Запускать собственные проекты, уходить в консалтинг или заказную разработку.
 
Когда ты понимаешь почему ты начал заниматься разработкой и что тебя больше интересует, выбор дальнейшего развития происходит на интуитивном уровне. 
 
Тебя прёт от работы с кодом и проектирования приложений?
Развивай техническую экспертизу. 

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

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

Главное не сидеть на месте. Иначе через 5-10 лет твои навыки уже не будут столь актуальными.
А возможно тебя вообще заменят алгоритмы машинного обучения. Відкрити / Коментувати

2021-04-09 10:03:37 Відкрити / Коментувати

2021-04-09 10:03:31 Друзья, буду очень признателен за поддержку!

Полтора месяца назад случайно попал на конкурс pet-проектов от Highload и решил оставить заявку. Мой проект прошел отбор и попал в топ-30.

Буду очень благодарен, если поддержите меня своим голосом тут

Чтобы найти мой проект в списке, нажмите в браузере CTRL + F и введите в поиск LMS. Номера проектов постоянно ротируются, поэтому сказать номер в списке не могу, скоро он будет не актуален. Відкрити / Коментувати

2021-04-07 09:31:04 Концентрация

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

Речь идет о концентрации - способности сохранять фокус внимания на одном занятии без переключения контекста. 

Умеете ли вы быть сфокусированным на протяжении 4-6 часов?

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

Достичь истинной концентрации и сохранять ее на длительном промежутке времени достаточно непросто. Я уверен, лимит продолжительности концентрации любого человека не превышает 6-8 часов в день. Однако даже 4-6 часов сконцентрированного труда могут заменить несколько дней работы с постоянными переключениями контекста.

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

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

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

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

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

Для высокого уровня концентрации также важно создать правильную обстановку и окружение. Для меня это:

- Режим "не беспокоить" на ноутбуке. Авиарежим на телефоне в первой половине дня.
- Качественный сон. Ни о какой концентрации не может идти речь если вы не выспались.
- Правильная музыка. Я люблю ритмичную электронику: ambient, deep house, dub techno и тд.
- Каждые 50-70 минут я делаю перерыв на 10-15 минут. Во время перерыва никаких соц. сетей и посторонних дел. В основном я растягиваюсь, делаю себе чай / кофе или выхожу на улицу подышать воздухом.

Также я уверен, что регулярный кодинг и написание текстов помогло мне развить способность удерживать внимание на одном деле по 5-6 часов без переключений контекста.

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

Иногда я туплю 1-2 часа над пустым документом и не могу ничего написать. Если я пересилил себя и не начал прокрастинировать, в результате получается новый пост или сценарий для YouTube видео.

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

Два года назад я прочитал книгу “Deep Work” от Кэла Ньюпорта. Уверен она есть в русском переводе. Крайне рекомендую для большего погружения в тему.

Учитесь сохранять концентрацию и быть сфокусированным. Ваша жизнь от этого станет только лучше. Відкрити / Коментувати

2021-03-31 09:31:01 Грамотная коммуникация
 
Недавно я писал о софт скиллах и их важности для личностного и профессионального роста. В этот раз я хочу заострить внимание на одном из ключевых навыков - грамотном письме. 
 
Грамотность, в данном контексте, означает способность ясно и четко доносить свои мысли с помощью текста - будь-то неформальное общение в мессенджере, деловая переписка по Email, сопроводительное письмо при отзыве на вакансию, документация проекта или комментарий на YouTube. 
 
Сильные текста продают товары, продукты, услуги и идеи. Четкие и лаконичные сообщения помогают экономить кучу времени при деловых переписках. Правильно подобранные слова дают возможность делиться сложными знаниями в простой и понятной форме.
 
Я уверен что культивация этого навыка принесет свои плоды любому, будь вы студентом, программистом, дизайнером, менеджером или предпринимателем. 
 
Умение грамотно доносить свои мысли с помощью текста становится еще более актуальным навыком при работе на ремоуте, поскольку большинство коммуникаций происходят асинхронно в формате переписки.
 
Я уже не раз приводил примеры компании Basecamp и тема этого поста не станет исключением. При приеме на работу они дают тестовое задание, процесс выполнения которого нужно описать в документе. Не важно кого они нанимают - программиста, дизайнера или оператора в службу поддержки - этот этап собеседования является обязательным для любой позиции. 

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

"We only hire good writers"
Jason Fried, CEO в Basecamp
 
Лаконичный и структурированный текст демонстрирует ясность мышления и порядок в голове. Это крайне важно для принятия важных, творческих решений и генерации новых идей.
 
Я всегда обращаю внимание на манеру письма своих коллег. За время работы в разных командах разработки я увидел достаточно интересную корреляцию: специалисты со слабо развитым навыком письменной коммуникации чаще пишут запутанный код с непонятными неймингами, плохой декомпозицией и неинформативными комментариями. 
 
Это и неудивительно. Язык программирования, как и обычный язык, это инструмент для рассказа истории. С помощью кода мы излагаем свое видение алгоритмов и бизнес-процессов. Как и текст, мы делим код на логические блоки с помощью функций и классов. 
 
Представьте что этот текст был бы написан одним абзацем, без переносов строк, запятых и с длинными предложениями. Уловить суть было бы намного сложнее. Та же логика применима к программированию на высокоуровневых языках, которые максимально абстрагируются от инструкций железу.
 
Чтобы лучше писать текста, следует практиковаться и читать литературу. Регулярное чтение позволяет расширять словарный запас и тренировать чувство грамотного письма.
 
Раз уж речь зашла за книги, рекомендую “Пиши, сокращай” от Ильяхова, которая разложит по полочкам то, что такое сильный текст и как его написать. Відкрити / Коментувати

2021-03-24 10:30:59 Знания в голове и в мире
 
Один из важнейших аспектов работы над проектом - коммуникация. От нее напрямую зависят скорость и качество конечных результатов. Выстроить правильные процессы общения крайне важно на старте любого проекта.
 
Сложность коммуникации коррелирует с количеством участников. Когда на проекте один человек, все достаточно просто. Он знаешь все о проекте, а его единственный возможный канал связи - это клиенты. Как только в команде появляются новые люди - сразу все становится сложнее.
 
К сожалению, пока еще нет технологии, которая бы позволила нам транслировать свои мысли и знания в голову другого человека. Поэтому все особенности и нюансы проекта, все идеи и гипотезы необходимо коммуницировать с членами команды.
 
Возникает вопрос, как эффективно организовать передачу информации? Умные люди уже давным давно придумали вести базу знаний: документацию, диаграммы, flow чарты и тд. К сожалению, далеко не все этим пользуются.
 
У меня был опыт прихода в компанию, где мне показали репозиторий с сотнями тысяч строк кода и сказали “разбирайся”. Никакой документации, никаких схем или диаграмм, ничего. Даже комментариев в коде не хватало. Знания по проекту находились у каждого из членов команды в голове, и передавались они из уст в уста.
 
Человеческий мозг - самое ненадежное хранилище. Знания могут теряться или искажаться. Человек может банально что-то перепутать или недоговорить. Передача знаний в устной форме неэффективна, плохо масштабируется и занимает много времени.
 
Когда я стартую проект, все начинается с концепт-документа. В нем я излагаю абсолютно все детали: высокоуровневую идею, проблематику, бизнес ценность, технические особенности, функциональные требования и тд.
 
В процессе работы я стремлюсь постоянно оставлять артефакты: комментарии в коде, небольшие документы с описанием архитектуры, flow чарты с демонстрацией основных пользовательских сценариев. Все это образовывает базу знаний по проекту.
 
Как только у меня появляется необходимость подключить нового человека, в первую очередь я делюсь базой знаний. Такой подход значительно упрощает коммуникацию и позволяет быстро провести onboarding новых участников команды.
Как я уже сказал, полагаться на свою память дело неблагодарное. Даже если я веду проект самостоятельно, все идеи и знания я описываю в документах, веду доску в Trello, рисую диаграммы и тому подобное. 
 
Это особенно полезно когда ты возвращаешься к работе спустя некое время. Подобные артефакты позволяют быстро вернуться в контекст и не упустить важных деталей. Відкрити / Коментувати

2021-03-17 10:30:21 Баланс качества
 
При разработке программного продукта хороший инженер стремится заложить идеальную архитектуру, написать безупречный код, достичь 100%-ое покрытие тестами, создать масштабируемое и отказоустойчивое решение. Это благие цели. Однако такой подход не всегда может позитивно сказыватся на конечном результате.
 
Сразу уточню, что все зависит от контекста. Следующие наблюдения применимы к молодым стартапам и заказной разработке с ограниченными сроками и бюджетом, но будут плохим советом для крупных Enterprise продуктов. 
 
При разработке больших энтерпрайз решений компания имеет много денег и времени. В таких условиях на первое место выходит качество разрабатываемого продукта. В стартапах и некоторых заказных проектах дела обстоят иначе. Там бизнес хочет быстро запуститься, валидировать идею и начать зарабатывать деньги.
 
Данный контекст непосредственно влияет на разработку. На начальном этапе имеет смысл отказаться от сложной архитектуры с кучей микросервисов, 100%-го покрытия тестами и пожертвовать лучшими практиками по написанию кода, что поможет сократить время выпуска продукта в продакшн. 
 
Главная цель на начальном этапе - сделать рабочую версию продукта, на который можно пустить трафик и получить первые результаты.
 
Будет ли это качественное решение? Нет.
Будет ли это масштабируемое и отказоустойчивое решение? Нет.
Будет ли этого достаточно на начале? Да.
 
Нужно держать в голове то, что клиент не заплатит вам за высокое покрытие тестами или красивый код. Он заплатит за рабочий продукт, который решает его проблемы, пусть даже он не будет идеальным на старте.
 
Много продуктов в начале создают из говна и палок. Когда идею провалидировали, появились первые клиенты и денежный поток, есть 2 варианта: все выбросить и сделать заново или привести до ума уже существующее решение. Какой вариант выбрать зависит от контекста и ресурсов.
 
Прелесть современной разработки в том, что так называемый Time to Market сейчас намного ниже чем 20-30 лет назад. 
 
Раньше разработчики создавали программный продукт несколько лет, после чего он записывался на дискеты или CD-диски (да, и такое было). Далее эти тиражи распространялись по всему миру, и если вдруг на этапе тестирования пропустили серьезный баг, исправить это было очень сложно.
 
Сейчас мы можем обновлять приложения хоть по 100 раз на день, поскольку запускаются они на наших серверах. Такой подход позволяет постоянно, итеративно улучшать продукт, параллельно обслуживая первых пользователей. 
 
Разработчики Basecamp запустили первую версию в продакшн без возможности приема платежей. Они знали, что после запуска у них есть 30 дней на решение этого вопроса. Первый год их приложение было развернуто на одном едином сервере. На данный момент этому приложению 15 лет и у них более 20 миллионов активных пользователей.
 
Плохой инженер делает как-нибудь, лишь бы работало.
Хороший инженер стремится сделать идеально, не вникая в бизнес.
Отличный инженер задает вопросы, пытается понять контекст и соблюдает баланс качества, исходя из ограниченности ресурсов. Відкрити / Коментувати

2021-03-10 10:30:55 ​​Неэффективность больших команд и ошибка преждевременного роста
 
В начале 2019-го я устроился инженером в достаточно крупный B2C стартап. Большая компания, огромный коллектив, эффектные корпоративы раз в полгода, собственный ресторан, тренажерный зал и занятия йогой прямо в офисе, который в свое время победил в международном конкурсе дизайна.
 
Концепция продукта - предоставить возможность пользователям обезопасить себя в сети с помощью широкого спектра фич, от проверки своих паролей на факт утечки до онлайн-покупок с помощью виртуальных кредитных карт.
 
На момент моего прихода в компанию команда состояла из +- 70 людей, на бекенде нас было четверо. Спустя полгода количество людей в организации удвоилось, в одном лишь отделе разработки работало порядка 50 специалистов.
 
Казалось бы, у бизнеса должно быть все просто замечательно. Компания растет, следовательно продукт стремительно развивается и приносит много прибыли. А чтобы его масштабировать и улучшать, топ-менеджмент решил набирать в команду все больше специалистов.
 
На деле же все выглядело совсем по-другому. Продукту не хватало самого главного - покупателей, которые хотят решать проблему личной безопасности в сети за ту стоимость, которую мы предлагали. В управлении продуктами есть такое понятие как product/market fit - именно он у нас отсутствовал.
 
Не смотря на это, организация тратила огромную часть бюджета на маркетинг и разработку, нанимала все больше специалистов. Это привело к тому, что в определенный момент половину сотрудников уволили. Еще через месяц проект закрыли.
 
Из этой истории и моего опыта работы в такой организации можно сделать несколько интересных выводов.
 
Первый и самый главный - при запуске продукта необходимо найти свое место на рынке, понять своего клиента и решать его проблему так, чтобы он был готов за это заплатить. Без этого все остальные действия не имеют смысла и ведут к провалу.
 
Не нужно заботиться о запуске дорогих маркетинговых кампаний. Не нужно думать про масштабирование на миллион пользователей. Не нужно раздувать штат персонала. Все это должно следовать уже после валидации продуктовой гипотезы и первой волны продаж.
 
Второй интересный вывод - большие команды контрпродуктивны. Основная причина этому - возрастающая сложность коммуникации. Это можно легко объяснить с помощью закона Меткалфа. Он гласит что эффективность сети пропорциональна примерно половине квадрата количества подключенных устройств к этой сети.
 
Этот закон можно легко применить и к группе людей. Чем больше в команде людей, тем больше количество потенциальных взаимосвязей, тем сложнее становиться организация и коммуникация внутри такой группы. Из-за этого много времени терялось на бесполезные митинги, обсуждения и передачу знаний другим коллегам / новым сотрудникам.
 
Ко всему этому, большая организация теряет гибкость и медленно реагирует на изменения, что крайне необходимо в условиях стартапа.
 
После того проекта я принял участие в разработке B2B стартапа в другой компании. За полгода мы разработали более сложный продукт с точки зрения технической реализации. Наша команда состояла из менее чем 10-ти человек, все работали удаленно.
 
Меня вдохновляют много разных компаний, одна из них - Basecamp и ее учредители Джейсон Фрайд и Дэвид Хейнемейер. Их главному продукту уже 15 лет, за это время они выросли до 20 миллионов активных пользователей. На данный момент в их компании работает 52 или 53 сотрудника, и это вместе со службой поддержки. Они осознанно отказываются от большого штата сотрудников, поскольку считают что это только навредит компании, о чем рассказывают в интервью и пишут в своих книгах Getting Real и Rework.
 
Больше не значит лучше и эффективнее. Часто даже наоборот. Раздутый штат не решит проблему отсутствия спроса на твой продукт. А с определенного количества специалистов, команда начинает терять свою эффективность. Відкрити / Коментувати