Как стать автором
Обновить

Зародыш, франкенштейн или корпорация — почему важно точно знать, где ты сейчас работаешь?

Уровень сложностиПростой
Время на прочтение8 мин
Количество просмотров4.4K
Всего голосов 11: ↑7 и ↓4+6
Комментарии14

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

В целом жизненная статья. Сам прошелся по всем этим фазам роста вместе с компаниями, в которых работал и работаю. Скажу, что самая нервная и трудозатратная фаза это трансформация из "стартапа-переростка" (по шкале автора) во что-то иное. Для себя на будущее решил ввязываться в это во второй раз только за очень понятные, материальные и достаточно большие бенефиты(например опционы на x2-x3 к зп) - иначе количество затраченных нервных клеток не стоит того.

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

Типа сидеть за N сумму на легаси проекте и плевать в потолок? Я пока еще не слишком стар для этого д..а))
Шутка если что. Никого не осуждаю - не для всех работа - хобби и не каждая работа должна быть хобби.

Не вижу никакой необходимости нанимать 100500 человек в компанию.

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

Странная градация, не очень представляю как стартапе-переростке могла собраться такая критическая масса в 30-50 разработчиков, которые работают без тестировщиков, автоматизации или планирования. Ладно СТО и менеджеры всякие встречаются, но остальных же надо специально таких нанимать.

Все естественно зависит от конкретного случая, но, в первую очередь, бизнес хочет делать функционал для клиента, и лучше, если быстро. Поэтому разработчики в таких случаях становятся T-shape, чтобы не расширять штат еще больше. То есть делают работу и разработчика и девОпса, и куа. И в этом случае, какими-то вещами будут пренебрегать.

Есть конечно и примеры полностью кроссфункциональных команд в стартапах, где сразу нанимают исходя из потребности X dev + Y qa + devOps +дизайнер + ПО. Но это обычно дороже, особенно в небольших масштабах.

Пока моя предыдущая контора не издохла в мучениях, успел собрать 15 кружек и это при том, что в последние пять лет их дарить перестали ))

Зато память теперь навека, и на внуков чашек хватит)) ну и иногда поностальгировать можно

Всё давно уже классифицировано)

Есть же такая штука - спиральная динамика. Это концепция, которая описывает стадии развития бизнеса. И там довольно чёткие критерии по фазам.

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

Да, в целом, почти любая тема имеет какой-то теоретический базис под капотом. Но лично мне всегда интересно изучать что-либо на практических примерах. И желательно узнавать это от людей, работающих в моей сфере(так как есть все-таки специфика), а не в государственных организациях, банках. Много книг написаны в 60-е - 80-е на примерах Американских компаний и их уже тяжеловато воспринимать.

Там наоборот недавняя тема. Бирюзовые организации - это новый модный тренд. А они как раз вроде последняя ступень спиральной динамики.

Не знал если честно, кажется стоит ознакомиться) Вот, узнал что-то новое сразу из комментов на Хабре, уже не зря статью писал.

А про спиралевидную структуру как я и думал написали в 60-е

В 1966 году американский доктор психологии Клер Грейвз опубликовал теорию спиральной динамики. 

В 2014 году Фредерик Лалу «раскрасил» по аналогии существующие компании.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий