Flex и MENstruation мне зашли больше всего.
Интересно оценить для сравнения изменения месседжей для аудитории пост-совка. Индекс рекламы прокладок — мы уже тоже или ещё не?
Ожидал увидеть больше деталей. Планировку офиса в разделе про офис. Модели ноутов и цены. Какие-то правила работы или выводы. Какие трудности, кроме интернета. Что с наймом и обучением временных сотрудников. Как боролись с текучкой. И т.д.
А тут получилась история, на которую можно ответить разве что "ну молодцы!".
Я за то, чтобы оставить концепцию коспекта, но дополнительно поискать другие аудитории, которым пригодится: студенты, ученые, авторы. Сделать англоязычным и продвигать как самый удобный инструмент для ведения конспектов. Может стоит сделать названия списков "делаем", "не делаем" кастомизируемыми. Для кого-то это будет "почитать об этом" и "проверить информацию".
Ребята из Бюро очень много полезного делают, как не быть фанатом)
По гибкости вам тогда зайдёт Management 3.0 Апелло. Название громкое, но по сути там просто идеи как можно применять гибкие методики разработки вне процессов создания ПО. А дальше уже знакомиться с самими методиками, например, Скрам и пробовать внедрять. Я тут профан, так что советов давать не буду.
Армию, конечно, тоже не люблю. Но тут практика проверенная временем и жизнями. Конечно, мы не на войне и руководим не мясом. Но вот именно в плане ответственности, кажется, все согласны, что коллективная работает гораздо хуже индивидуальной.
Спасибо разрабам Виси за ограничение в 5000 символов. Стимулируете обстоятельную дискуссию?
ПРОДОЛЖЕНИЕ
Теперь о ключевой идее манифеста. Она мне не нравится. Разделить ответственность на группу, мне кажется, гарантирует невыполнение задачи. В этом плане стоит учиться у жестких иерархических организаций, например, армии. Представьте, чтобы на поле боя тактические решения принимала группа вместо одного генерала.
Мне кажется, ответственный должен быть один, а остальные подключаться по необходимости. Я бы вам посоветовал завести задачник для команды, который позволяет организовать следующее. В любую задачу можно включить любого сотрудника, но отдельно обязательно указать одного ответственного исполнителя. Я пользуюсь Планфикс, но вам он может не подойти. Еще раз важные моменты:
1) У задачи обязательно есть один исполнитель
2) В задачу можно подключить любого сотрудника или даже контакт без аккаунта в задачнике.
Ни в коем случае не переводите работу из чатов в другие чаты или почту. Только в задачник и как можно скорее.
Далее вы пишете:
Если один из участников не тянет, другой вполне может ему напомнить, что он забыл что-то сделать.
Это тоже в идеале должен помогать делать задачник — подсказывать, если задача давно не обновлялась. У меня пока не работает, но представляю как можно настроить. Фолбек — руководитель просматривает задачи, где его подчиненный ответственный и выписывает пиздюлины управленческие воздействия, если задача зависла.
Советую почитать в порядке убывания важности:
Жесткий менеджмент Кеннеди
Личную продуктивность Кеннеди
Курс Максима Дорофеева
Управление проектами Товеровского
для старта о том, как "сделывать" проекты в посте 'Что значит "Сделать"'
Весь Адизес
Хочется что-то по менеджменту, управлению проектами и мотивации персонала, но всё так разбросано, что и не выделишь кого-то одного. Разве что покопаться у Брайана Трейси или попробовать по гибкому управлению что-то взять — методики из разработки ПО вполне себе пригодны и в других сферах.
Ну и на конец. Ваш бизнес не рухнет, по крайней мере от этих экспериментов. Вы сталкиваетесь ровно с теми же проблемами, что и тысячи фаундеров. Читайте, пробуйте, переделывайте —всё по классике. Успехов!
Привет, Михаил!
Спасибо, что делитесь опытом и не стесняетесь говорить о проблемах. Советчиков с "не ваше это дело" смело шлите нахуй. Очевидно, что они не были на месте основателя компании и не знают, о чем говорят.
Я 10 лет руковожу собственным бизнесом без партнеров и до 35 сотрудников в разное время. Хорошо понимаю вашу боль. Сам сталкиваюсь с необходимостью принимать много очень разноплановых решений на всех уровнях: от выбора принтера в офис и собеседования уборщицы до плана продаж на год вперед и управления инфраструктурой на AWS.
Необходимость принятия решений — это симптом, и тут непосредственно его нечего обсуждать. Принимать решения, имея достаточно информации, легко. Проблема обычно в другом. Чтобы проработать задачу и получить эту информацию, нужно время, энергия и компетенция. Для этого мы и нанимаем людей.
Дальше попробую резюмировать свой опыт. Кстати, многие проблемы до сих пор не решены. Я не претендую на лавры бизнес-гуру и проповедника. Мои советы могут не работать в вашем случае. Просто надеюсь, что будут полезными.
С ростом бизнеса нанимать средний уровень менеджмента. В вашем случае это может быть руководитель операционного и сервисного отделов, так как в каждом из отделов пока всего по двое сотрудников.
Когда я год назад нанял руководителя клиент-центра (у меня интернет-магазин), это стало огромным облегчением. Значительная часть вопросов стала решаться уровнем ниже без моего участия. Правда, позже выяснилось что часть проблем решались очень криво и меня все-таки надо было привлечь. Но тогда я не смог бы заниматься другими сферами. Сейчас уволил человека с этой позиции, меня завалило запросами, но зато вижу много возможностей для улучшения процессов. Похоже, надо делать именно так: ставить человека на какую-то зону, и периодически работать за него или очень глубоко вместе с ним, чтобы растрясти то, о чём он молчит (не со зла, конечно).
Нанять операционного или исполнительного директора. Этого я не сделал до сих пор и очень жалею об этом. Так же, как и с предыдущей ролью, есть сильный страх, что всё пойдет по пизде, но есть и подозрение, что даже если неподходящий сотрудник будет справляться на 30% — это лучше, чем без него.
Учиться отказываться от чужих обезьян. Люди склонны переваливать ответственность на руководителя, если тот позволяет. Согласен с одним из комментаторов (или это были вы?), что надо включать в процесс найма оценку способности самостоятельно принимать решения, но сам такое не умею.
А вот что можно сделать уже сейчас, не надеясь поменять "плохих" сотрудников на "хороших". Каждый раз, когда вас просят решить что-то, спрашивать себя:
1) достаточно ли это важное решение, чтобы им занимался я?
2) могу ли я доверить этому сотруднику решить самому?
3) что будет, если он сделает не так, как сделал бы я?
В некоторых случаях вы сможете ответить себе: "Да похер, пусть разберется сам!". Знаю, это очень трудно. Особенно, если вы, как и я, PaEi по Адизесу.
Систематически поощряя принимать решения самостоятельно, вы сможете вырастить в людях уверенность и снимете с себя часть проблем. Но будьте аккуратны: если вам не понравится то, что сделал подчиненный, надо деликатно поправить его, чтобы не отбить желание принимать решения в будущем. Будьте готовы, что временами вам будет казаться, что они вообще всё делают через жопу. Я всё еще учусь отделять свой перфекционизм от действительно плохо сделанной работы.
Никогда не давать готовое решение группе, даже если ты уже придумал, как надо сделать лучше. Посмотреть, что у них самих получится.
Полезно, если есть время и задача некритична. Можно сначала давать время разобраться и предложить свои варианты, потом в обсуждении, задавая вопросы, проверить хорошее ли решение предлагает сотрудник. Например, "а что будет, если у партнера изменится шаблон накладной? Как будет работать твой парсер?". Если в процессе выявили слабые места, можно предложить подумать в сторону вашего варианта, но не спешить называть его. В идеале подвести сотрудника к вашему решению так, чтобы он думал, что оно его.
Все советуют отстраивать бизнес-процессы. Тут важно понимать, когда это уместно в плане этапа жизненного цикла компании. На старте бизнес-процессы могут мешать. Их надо отлаживать, начиная с самых статичных, т.е. таких что скорее всего не будут скоро перекраиваться. Обычно советуют начинать с самого главного, например, процесса продаж или обработки заказов. В 2014 я поставил процесс создания товаров на сайте с контент-менеджером. Там уже четыре года ничего не меняется — я не заглядываю.
Иногда они формируются автоматически, если задача стандартизована и уже встречалась раньше.
Если задача уже встречалась, ставьте процесс: напишите короткую инструкцию в ГуглДоках и выберите ответственного. В идеале, если ответственного назовете не "Коля", а, скажем, "Менеджер проектов". Потом при смене Коли на Алексея дадите Алексею все доки с инструкциями для менеджера проектов.
Конюшни Агнии Барто?)