У многих компаний два основателя

У многих компаний два основателя

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

Сейчас у Nimax целая команда руководителей, каждый из которых партнер в своем подразделении. Но долгое время мы с Максимом управляли компанией вдвоем. Более того, мы еще и учились в школе, а затем в институте вместе. А сейчас живем в одном доме и дружим семьями. В общем, мне есть что рассказать про взаимоотношения партнеров в проекте.

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

Еще у меня накопился целый список других проблем, которые мы когда-либо обсуждали с коллегами из других компаний:

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

Знакомо? Ну да, проблемы у всех одинаковые 🙁
Можем разобрать некоторые из этих ситуаций — напишите какие.

Культ своего бизнеса

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

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

Нищих и грустных фаундеров не меньше, чем румяных и счастливых наемников. 

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

Так называемая свобода хранится в голове, а не в правовой форме организации работы. 

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

Подсчёт потоков

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

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

Давайте представим обычный день замерщика. Во первых, подсчет — это коллективная работа. Несколько человек выходят на заранее отмеченные методологами места, и в одно и то же время начинают замеры. Тут кроется первая проблема — замерщикам нужна карта и специальные инструменты. Методологи подготавливают эти материалы: размечают местность на карте, наносят сечения и точки расположения замерщиков. Распечатывают их, а так же специальные бланки, куда замерщики должны занести результаты. Соответственно, полевику необходимо обязательно заезжать в офис, чтобы забрать материалы и кликеры.

Приехав на местность, замерщикам необходимо коммуницировать как между собой, так и с исследователями. Общение происходит в телеграме. Проблема в том, что команда очень чувствительна к опозданиям и, тем более, к неявке — от этого может пострадать вся работа. Исследователям практически невозможно проследить за тем, чтобы полевики начали работу в нужное время, ещё сложнее, проследить за тем, чтобы никто не подделал свои замеры (так как сделать это несложно). Единственный способ — это чтобы в команде был хотя бы один проверенный полевик, выполняющий роль супервайзера.

Итак, замерщик занял свою позицию, и начал вести подсчет. Проблема в том, что одновременно можно использовать только два кликера (по одному в каждой руке), тогда как категорий потоков может быть гораздо больше (легковой, грузовой автомобиль, общественный транспорт, велосипед и т.д.). Приходится держать информацию в голове и, по возможности, переносить их в бланк, который нужно держать неподалеку. Бланк бумажный, а теперь представьте, что на улице холодно и идет мелкий дождь…
Замер происходит в пиковые часы, в течении 15 минут. Потоки, в это время, могут быть очень интенсивными.

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

Сила разговора

Сила разговора

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

Дальше попытались найти секретный ингредиент, что именно помогает людям при работе с психологом.

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

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

Работа в офисе

Что думал в начале 2019:
- По-настоящему эффективно работать можно только вместе, лицом к лицу с людьми.
- Самые крутые продукты создаются в офисах. Apple, Google, Facebook, Spotify, Tesla, SpaceX, что угодно — у всех есть Главный Офис, где и придумывается всё самое интересное.
- Удалённо работать могут только фрилансеры над отделяемыми неважными задачами.

Что думаю в начале 2020:
- Будущее за распределёнными компаниями и удалённой работой.
- Если у компании несколько офисов — это уже распределённая компания. Если на большинстве встреч ты созваниваешься с людьми по видеосвязи, то не так уж и важно, сидят ли они в другом офисе, в кафе или у себя дома.
- Figma, Slack, Notion, Miro, Loom и многие другие инструменты позволяют работать совместно, как будто вы сидите за соседними столами, даже если на самом деле вы в разных концах Земли.
- В работе бывают моменты, когда вы что-то придумываете, формируете — и тут правда есть ценность в том, чтобы быть физически в одной комнате, рисовать на одной доске. А есть моменты, когда основы придуманы и надо просто сфокусированно фигачить. И вот тут офис нередко может больше мешать, чем помогать.
- Города не резиновые. Если стремиться перевозить высокооплачиваемых айтишников со всего мира в один город, качество жизни там падает для всех. Посмотрите на Сан-Франциско. Дублин, кстати, рискует повторить ту же историю. В будущем всё больше людей будут жить вообще вне городов, потому что для работы достаточно хорошего интернета.

7 важных факторов PHP-приложения

7 важных факторов PHP-приложения

Инженеры платформы Heroku (https://www.heroku.com/) на основе собственного опыта создали методологию (https://12factor.net/ru/) для разработки SaaS-приложений.

Эта методология учитывает три важных аспекта:
— расширяемость — развитие кодовой базы и функционала;
— сопровождаемость и возможность командной работы над проектом;
— масштабируемость.

12 факторов приложения стали шаблоном для многих разработчиков и Ops-инженеров, а мы постарались адаптировать самые важные из них для приложений на PHP.

Кодовая база (https://12factor.net/ru/codebase). Забота о коде начинается с принципов его версионирования и хранения. Используйте Git Flow или его адаптацию с учетом специфики работы ваших команд.

Зависимости (https://12factor.net/ru/dependencies). Используйте менеджер зависимостей Composer (https://getcomposer.org/) и его основные операции install и update для манипуляций c composer.json (https://getcomposer.org/doc/04-schema.md) и composer.lock.

Конфигурация (https://12factor.net/ru/config). Предпочтительным методом обработки конфигурации является использование переменных среды. Для работы с ними мы применяем компонент symfony/dotenv (https://github.com/symfony/dotenv).

Параллелизм (https://12factor.net/ru/concurrency). Выполняйте процессы в фоне, тем самым снижая время отклика при взаимодействии с вашим сервисом. Выделяйте веб-процессы в реальном времени и рабочие процессы. Первые принимают http-запросы от клиента, а вторые — выполняют фоновые задачи, например, с помощью брокера сообщений RabbitMQ (https://github.com/rabbitmq).

Паритет разработки/работы приложения (https://12factor.net/ru/dev-prod-parity). Для того чтобы обеспечить схожесть сред разработки, тестирования и продакшена, мы используем виртуализацию на основе Docker и специально подготовленные образы, содержащие одинаковые наборы и версии библиотек. Промышленные и тестовые среды отличаются лишь степенью масштабирования, на основе технологий K8S и Swarm.

Журналирование (https://12factor.net/ru/logs). Фактор утверждает, что приложение должно просто писать в STDOUT и STDERR, а среда должна отвечать за маршрутизацию этих сообщений в хранилище. Технология PHP-FPM позволяет производить вывод логов в STDOUT, что крайне полезно при работе с Docker-контейнерами. Для организации процесса логирования на уровне приложения мы используем сторонние внешние библиотеки, например Monolog (https://github.com/Seldaek/monolog) или компоненты фреймворков.

Задачи администрирования (https://12factor.net/ru/admin-processes). Реализовать сценарии администрирования приложения можно с помощью внешних библиотек, например Symfony Console (https://github.com/symfony/console). Большинство современных фреймворков имеют встроенные средства для организации запуска консольных команд для служебных целей и миграций. Например, в Yii Framework есть понятие консольного приложения (https://www.yiiframework.com/doc/guide/2.0/en/tutorial-console) и команды.