Русский
Русский
English
Статистика
Реклама

Управление проектами

Какие проблемы может выявить аудит прав доступа и что с этим делать

21.01.2021 10:23:56 | Автор: admin
Управление доступом один из самых непростых моментов в любой немаленькой компании. Для того чтобы все было по уму, должна быть налажена совместная работа между ИТ-отделами, подразделениями безопасности, кадровиками и руководителями групп и подразделений. И без аудита прав доступа здесь не обойтись. Он может быть как внутренним, так и внешним. Очевидно, что проблемы лучше выявить и устранить на этапе собственной проверки, чем потом получить по голове от регулятора или доиграться до утечки информации либо другого крупного инцидента.

В этой статье я расскажу о том, какие проблемы можно выявить при аудите прав доступа в компании и как можно упростить себе жизнь с помощью современных IdM/IGA-решений (Identity Management/Identity Governance and Administration).



Нарушения есть? А если найду?


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

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



Суть аудитов не слишком изменилась с тех времён. Как говорит нам современный Вики-словарь: Аудиторская проверка процедура независимой проверки и оценки отчётности, данных учёта и деятельности организации, а также системы, процесса, проекта или продукта.

Со временем термин проник и в другие сферы, в том числе в ИТ в целом и информационную безопасность в частности; есть специально разработанные стандарты для отделов информационных технологий в любой организации. COBIT пакет международных и национальных стандартов и руководств в области управления IT и аудита IT-безопасности. Европейский стандарт GDPR, охватывающий широкий спектр вопросов безопасности и защиты данных. Международный стандарт безопасности данных индустрии платежных карт PCI DSS и т. д. Уровень соответствия таким стандартам можно установить с помощью аудита.

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

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

Зачем нужен аудит прав доступа


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

Аудит и отчетность это не только про обязаловку и контроль ради контроля. Они все-таки имеют ценность с точки зрения безопасности, поскольку направлены на соответствие требованиям и стандартам в любой информационной среде. Аудит позволяет выявить аномалии, контролировать доступ пользователей и выбирать правильные инструменты для обеспечения бесперебойной работы.

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

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

Какие проблемы можно выявить с помощью аудита


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

Незаблокированные учетные записи


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

Накопление прав


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

Бесхозные учетные записи


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

  • Они дают доступ к почтовым ящикам, к учетным данным приложений, к конфиденциальной информации, и бывшие владельцы учетных записей или злоумышленники могут добраться до ценных ресурсов и нанести вред компании.
  • Иногда они функционируют, когда это уже не требуется, и потребляют ресурсы или пропускную способность. Такая проблема особенно часто возникает с техническими учетными записями определенных служб. Несколько приложений могут продолжать использовать бесхозную учетную запись из-за ошибки или неправильной конфигурации. Например, когда из-под технической учётки регулярно стартует задание: выгружает из центральной системы на клиентский сервер большой массив данных, которые когда-то были актуальны для обработки и аналитики, но со временем эту актуальность потеряли или были заменены на другие инструменты. Но задание так и продолжает молотить ежедневно, съедая ценные ресурсы и перегружая систему.
  • Бесхозная учетная запись, когда под ней долгое время никто не работает, выпадает из поля зрения действующей политики и требований безопасности. Требования не применяются к ней и не обновляются. Например, у такой учетки может оказаться слабый или скомпрометированный пароль.
  • Бесхозные учетки часто используются совместно несколькими сотрудниками. Это повышает риск несанкционированного доступа, а идентифицировать того, кто нанес вред компании, порой просто невозможно.

Слабые пароли и их ненадежное хранение


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

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

Небезопасное хранение данных на сетевых ресурсах


Каждая организация за годы эксплуатации систем генерирует огромные объемы информации, которые с течением времени только увеличиваются. По оценкам аналитической компании Gartner, как минимум 80% корпоративных данных являются неструктурированными. 7 из 10 пользователей имеют доступ к данным, которого у них быть не должно. Аудиторские проверки во многих компаниях выявляют следующее: конфиденциальная информация, которая хранится на файловых серверах, в облачных хранилищах, на корпоративных порталах, в общих ящиках электронной почты и т. д., не защищена и доступна множеству сотрудников. А это может привести к серьезным инцидентам ИБ: личные данные клиентов и сотрудников, коммерческие предложения, закрытые исследования и прочие секретные сведения могут быть украдены. Кроме того, в некоторых случаях хранение данных должно соответствовать законодательству (например, персональные данные) или стандартам (например, PCI DSS).

Несанкционированный доступ


Часто аудиторы просят продемонстрировать, что пользователю были предоставлены та или иная учетная запись и права в информационной системе на основании утвержденной политики. То есть необходимо показать, что это была автоматизированная процедура или запрос в системе самообслуживания, кем были подтверждены/согласованы такие права, были ли учтены правила разделения обязанностей SoD, какими средствами запрос был исполнен и др. По сути нужна вся сохраненная история по всем этапам таких процессов. Подобные вопросы могут поставить в тупик сотрудников ИТ- и ИБ-подразделений, потому что нередко такую информацию очень сложно найти либо она вообще не сохраняется.

Используем решения класса IdM/IGA


Самое очевидное, что мы можем сделать со сбоящими в ручном режиме процессами, автоматизировать их. Контролировать процессы управления доступом, обеспечивать соблюдение политик и процедур позволяет система класса IdM или IGA. Она получает кадровую информацию о работниках компании и автоматически управляет их учетными записями и правами во всех подключенных системах на основании действующей политики. Давайте снова пройдемся по списку проблем, которые можно выявить при аудите, и я расскажу, как их решает автоматизированная система управления правами доступа.

Проблема с незаблокированными учетками решается автоматической блокировкой. Она происходит моментально, как только увольнение зафиксировано в отделе кадров. Кстати, для ряда компаний, особенно финансовых, это одно из требований регуляторов, например, в части соблюдения стандарта PSI DSS (немедленный отзыв доступа для уволенных работников и необходимость деактивации неактивных пользовательских аккаунтов по истечении 90 дней).



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

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

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



Подключая дополнительные модули, мы можем вообще отказаться от кучи паролей, на радость сотрудникам. Например, служба аутентификации SSO (Single Sign-On) позволяет использовать один набор учетных данных для входа в несколько приложений. Система сама автоматически подставит сложные и безопасные пароли в нужное время и будет хранить их в секрете даже от самого пользователя. Если применять альтернативные средства аутентификации (смарт-карты, биометрию и т. п.), можно полностью отказаться от использования паролей самим сотрудником. А безопасность при этом не пострадает.

Решение класса IdM/IGA в комплексе с системами класса DAG (Data Access Governance) помогут разобраться с небезопасным хранением больших объемов неструктурированных данных, точнее, упорядочат сами данные и контроль за ними. Комплексные решения позволят выявить и категоризировать данные, обнаружить конфиденциальные и наиболее ценные для компании активы, а автоматизированные средства позволят проводить регулярный пересмотр прав доступа к ресурсам и отзыв прав у тех, кто в таком доступе не нуждается. Благодаря постоянному мониторингу пользователей, получающих доступ к критичным данным, мы сможем на ранней стадии выявлять угрозы, обнаруживать утечки и реагировать на них.

Автоматизированная система IdM/IGA способна решить проблему с несанкционированным доступом, внеся определенный вклад в приведение корпоративных систем в соответствие требованиям регуляторов. Сразу скажу, это не панацея, но одна из возможных составляющих решения задачи. Как это может помочь:

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

Во-вторых, решения класса IdM/IGA позволяют безопасно разграничивать доступ на основании использования ролевой модели. То есть базовый доступ для сотрудников каждого отдела, управления, департамента и т. п. предоставляется на основании заранее определенных ролей. С помощью автоматизированной системы можно поддерживать и легко модифицировать ролевую модель при изменениях структуры компании или функционала сотрудника. Регулярные пересмотры прав доступа позволяют избежать накопления излишних прав и поддерживать их в актуальном состоянии. С помощью матрицы конфликтов полномочий (ролей) SoD (см. скриншот ниже) можно настроить различные сценарии реагирования на совмещение критичных прав.



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

Выводы


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

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

Автор: Людмила Севастьянова, менеджер по продвижению Solar inRights
Подробнее..

Recovery mode Хабрастыд-2020

04.01.2021 14:06:43 | Автор: admin
Привет, Хабр! В конце каждого года принято подводить различные итоги и Хабр не стал исключением. Лента наполняется темами типа топ ЯП по итогам 2020, топ 10 технологий, топ 20 работодателей, тысячи их. Но чего нет так это списка зашкваров года, которые подарили нам IT-компании и которые вызывают чувство испанского стыда. Надо сделать, подумал я и составил такой топ сам. Почему, зачем и собственно сами герои под катом. И прошу не судить строго, это мой первый, чисто развлекательный пост.

Каин после убийства своего брата Авеля Анри Видаль 1896 г.



Это уже было в Симпсонах


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

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

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

Зачем


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

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

Копирасты года Wargaming


Ещё 17 декабря 2019 года, картофельная танковая фабрика оскандалилась тем, что начала юридически преследовать своих бывших сотрудников в судах Беларуси, Кипра и США за работу над опенсорс проектом движка движка DAVA Framework/DAVA Engine, который она официально развивала до весны 2018 года. Поддержка проекта в качестве опенсорс официально декларировалась Wargaming на многих конференциях, в статьях, интервью и других источниках. Но потом, пять незадачливых выходцев из Wargaming, которые на данный момент работают в БлицТим, получили персональные иски и требование компенсации в виде $1 690 000.

Вышеупомянутые сотрудники ранее работали в минском центре разработки кипрской группы компаний Wargaming и принимали непосредственное участие в разработке игры World of Tanks Blitz и движка DAVA Framework/DAVA Engine, который потом использовали в собственном проекте Battle Prime. Когда проект (выглядящий, между прочим, очень годно) был представлен, картофельная фабрика золотых снарядов его тоже оценила и захотела поиметь свой гешефт.

Сейчас сутяги из Wargaming делают вид, что ничего криминального не происходит, не комментируют ситуацию и всё также клепают посты в своем бложике про то, какие они молодцы. В Верховном суде Беларуси танкофилы уже проиграли. Пожелаю парням из БлицТим удачи, а киприотам-золотоснарядникам из Wargaming дарю своё презрение. Кто хочет следить за процессом может делать это тут.

Работники года ДИТ


Или Департамент информационных технологий города Москвы (чувствуете, как повеяло номенклатурой?). Про дела этих ребят вы наверняка слышали, ведь 2020 для них выдался ну очень продуктивный. Если пандемия застала вас в Москве, то, возможно, вы даже были вынуждены пользоваться их говносервисами (под угрозой штрафа).


Криво работающие Цифровые пропуска получающие разрешение на отправку рекламы на следующие 10 лет, забагованный Социальный мониторинг, наспех собранный из кода трекера мусоровозов и обязывающий людей раз в 3 часа делать селфи и отсылать на проверку, откровенно шпионское Госуслуги СТОП Коронавирус (это реальное название от богов нейминга) все это поделки этих ребят. При этом их бюджет в 2020 составил 80 млрд руб. Как говорится, делайте выводы господа. Что забавно, по собственной оценке бракоделов из ДИТ все это позволило Москве избежать самого опасного сценария, который был в Италии и других европейских странах. Ага, конечно, особенно если отчётность по заболевшим можно подкручивать.

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

Перевозчики года Яндекс.Такси


В рамках освещения ситуации по делу Ивана Голунова, издание Медиазона получило комментарий пресс-секретаря ЯТ Натальи Рожковой о том, что сервис передаёт силовикам данные о поездках своих клиентов по первому же запросу, даже если он прислан с почты на мейлру, а не в официальном виде. Именно от ЯТ, один из экс-полицейских, сейчас проходящий обвиняемым по делу Голунова, узнал его домашний адрес.

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

Яндекс.Такси нет в реестре организаторов распространения информации, то есть сервис имеет право не предоставлять правоохранителям никаких данных, но всё равно делает это, видимо, по дружбе. Отмечу, что отдельного блога на Хабре у компании нет, может, даже и к лучшему.

Связисты года Yota



Можно как угодно относиться к ФБК, их фюреру и их деятельности (мне, например, нравится их блог на YouTube), но в 2020 с их подачи в этом посте можно упомянуть компанию Yota, которая незаконно отключила связь одному из самых известных сотрудников ФБК Руслану Шаведдинову в момент, когда силовики ломали дверь в его квартиру, чтобы не дать ему возможности оповестить родных или адвоката о происходящем, и спустя несколько дней даже не удосужилась прокомментировать эту постыдную историю. Позже стало известно, что Yota ещё и установила особый режим для номера Шаведдинова, при звонке, на который сообщается, что абонент находится не в сети. Также к номеру прикреплена плашка с пометкой обо всех действиях по номеру сообщать в PR.


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

Телеком вообще не жалует Хабр, вот и у Йоты нет блога, а их аккаунт с положительной кармой, уже 2 года молчит.

Карьерная возможность года Wildberries


Случай, который на Хабре не освещен был вообще. В конце сентября закрыли крупный проект из 30 человек, а от руководства поступило указание сократить на некоторых проектах 30% штата. Такое случается, конечно, но это было лишь начало.


29 ноября руководительница группы мобильной разработки в Wildberries Татьяна Аверьянова рассказала о массовых сокращениях в компании. По её словам, маркетплейс увольнял сотрудников целыми командами по собственному желанию, не выплачивая компенсации. А уже 30 ноября в офисе увольнялось столько людей, что отдел кадров и бухгалтерия не справлялись с обработкой и выдачей документов, часть попросили прийти за доками позже.

Также она рассказала о том, что Wildberries задерживает зарплату, технику для работы выдаёт сотрудникам только в аренду за плату. Компания приостановила набор новых сотрудников и иногда отзывает уже отправленные кандидатам предложения. В Wildberries, конечно же, все отрицают. Но рейтинг и отзывы об этом корейском онлайн-базаре на Хабр.Карьере как бы намекают на истинное положение дел.

Стыд года Рамблер


В этой номинации и не могло быть другой кампании, ведь инциденты подобные этому происходят чуть ли не раз в несколько лет. Данная история была широко освещена на самом Хабре и за его пределами, поэтому я не буду детально ее пересказывать. Кратко напомню, что в декабре 2019 Рамблер спустя 18 лет начал судебное преследование своих бывших сотрудников Игоря Сысоева и Максима Коновалова, пытаясь отжать у них права на самый популярный в мире веб-сервер Nginx, который был создан в 2002, когда Сысоев работал в Рамблере сисадмином. Незадолго до этого, Nginx был куплен американской корпорацией F5 Networks за $670 млн. Узнав об этом, в Рамблере жутко возбудились и посчитав, что Nginx был создан в служебное время, и заявили о своих правах на проект. Немедленно было возбуждено уголовное дело, а в офисе у Сысоева и Коновалова даже прошли обыски. Претензии предъявила компания Рамблер, хотя формально обвинителем стала Lynwood Investments CY Ltd, которой передали на это права. Последняя связана с совладельцем Rambler Group Александром Мамутом.

Реакция общественности не заставила себя долго ждать и IT-аудитория облила Рамблер таким потоком говна, что долетело даже до самого Германа Грефа, который через своего зампреда Льва Хасиса, который на тот момент был председателем совета директоров Рамблера, был вынужден вмешаться. В итоге в 2020 Рамблер попросил прекратить уголовное дело о правах на Nginx, исключив себя из числа потерпевших. Правда теперь истцом станет кипрская Lynwood, продолжив разбирательство уже в международном суде.

На Хабре у Рамблера есть блог, который они в последнее время начали оживлять и практически никто уже не припоминает компании этот стыд.

Что забавно, сам Хабр показал себя в этой истории довольно неоднозначно. Ситуация с Nginx сподвигла написать пост самого Денискина, редакция вела хронологию инцидента, а на главной была даже специальная ссылка, позволяющая держать руку на пульсе ситуации. Но это всё не помешало пригласить Рамблер в марафон удалёнки. Как говорится, вы не понимаете, это другое. В целом понятно желание быть IT-Швейцарией, но тут либо крестик снимите, или трусы наденьте.



Заключение


Надеюсь, в 2021 будет меньше стыда за наше родное айти, а все провинившиеся реабилитируются выпуском крутых опенсорс продуктов (например). Учитывать инфу из этого поста при устройстве на работу в такие компании, при одобрении активности их на Хабре или конфах? Каждый решает сам.

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

Минутка заботы от НЛО


Этот материал мог вызвать противоречивые чувства, поэтому перед написанием комментария освежите в памяти кое-что важное:

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

Что делать, если: минусуют карму | заблокировали аккаунт
Кодекс авторов Хабра и хабраэтикет
Полная версия правил сайта
Подробнее..

Эстимирование дизайна

12.01.2021 14:15:46 | Автор: admin

Меня зовут Илона, я Senior Experience Designer в EPAM. Работа для меня удачно совпадает с хоббив EPAM я проектирую интерфейсы для зарубежных заказчиков, читаю лекции для сотрудников и студентов лабы, менторю дизайнеров. В свободное время преподаю проектирование интерфейсов в магистратуре Университета ИТМО и ведуТелеграм-канал о UX-дизайне.

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

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

Проект и дизайн-команда

Проект, на котором мы работаем крупная e-commerce платформа с большой командой (80+ разработчиков, менеджеров, аналитиков, тестировщиков) и быстро меняющимися требованиями. На таком крупном проекте логично образовалась дизайн-команда из 4 ролей:

  • UX-дизайнер, задача которого выяснить требования и сгенерировать наиболее удобное пользователям решение.

  • UI-дизайнер (в EPAM эта роль также именуется Visual-дизайнер), который отвечает за то, чтобы интерфейс был красивым, эстетичным, хорошо смотрелся на разных разрешениях, соответствовал концепции бренда и возможностям разработки.

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

  • Team Lead, который налаживает процессы и решает оргвопросы, обеспечивает команде комфортные условия работы и также занимается UX-дизайном.

Процессы в проекте построены вокруг Scrum: планирование спринта с оценкой задач, двухнедельный спринт, ревью и ретроспектива. Задачи команда оценивала в часах: сколько по времени успеваем столько и берём в следующий спринт. Звучит просто, но оценка в часах вызывала большие трудности у дизайн-команды.

В целом, задачи на дизайн сложно оценивать в силу нескольких причин:

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

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

  • Каждую идею нужно проверить и утвердить с заказчиком. И не так просто понять, сколько времени это займёт и как результат обсуждения повлияет на работу дизайнера.

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

Вот некоторые цитаты из ретроспектив, которые мы проводили внутри дизайн-команды:

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

Относительная оценка сложности

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

Согласно Scrum, для оценки задач используется абстрактная единица Story point. В одной команде ею могут измеряться часы, в другой дни, в третьей что-то ещё. Кому как удобно.

В нашей команде 1 Story point был равен 4 часам. И нам, по перечисленным ранее причинам, было крайне тяжело оценивать работу в таких Story points. Поэтому я решила наделить Story point другой мерой сложность.

Сложность (complexity) количество усилий, необходимых для выполнения задачи.

В нашем случае оценка сложности в Story points оказалась гораздо эффективнее, чем оценка часов, потому что:

  • Оценка сложности помогает сконцентрироваться на создании ценности, а не погоне за временем. Мы перестали пытаться успеть хоть что-то в заявленные сроки.

  • Проще включить обсуждения, подтверждения и брейнштормы в итоговую оценку.

  • Заказчик лучше воспримет: задача очень сложная, чем мне нужно в два раза больше времени на выполнение задачи.

  • Исключаются обсуждения в формате Я бы сделал эту работу быстрее.

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

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

Параметры сложности

Сложность комплексная мера, и трудно сходу сказать, что это значит. Для удобства дизайн-команды я разделила сложность на 4 параметра*:

  1. Зависимости от других людей

  2. Навыки дизайнера

  3. Количество коммуникации в рамках задачи

  4. Согласованность нового дизайн-решения с уже существующими

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

Для каждого параметра я подобрала шкалы от 1 до 4. Например, оценка параметра Зависимость (Dependency) выглядит так:

1 (нет сложности) никто кроме дизайнера не вовлечён в работу, нет зависимости от других людей;

2 (низкая сложность) 1 человек вовлечён и немного работы с стороны;

3 (средняя сложность) 2-3 человека и/или много работы со стороны;

4 (высокая сложность) более 3 человек и/или невозможно определить количество работы со стороны.

Подробные шкалы по всем четырём параметрам сложности можно найти в моём докладе для конференции Design Z Day:

Как понять, что сложно, а что нет

Всё познается в сравнении.

Если время можно определить конкретно (например, два часа), то с оценкой сложности возникают проблемы. Что значит сложно? Где грань между сложно и очень сложно?

Секрет относительная оценка. Задачи оцениваются не в вакууме, а относительно друг друга, в сравнении.

Чтобы измерить сложность задачи в абстрактных Story Points, нужно сравнить две задачи и понять, насколько одна сложнее другой.

Например, задача 1 переделать форму входа на сайт. Задача 2 переименовать кнопки на странице регистрации. Задача 1 явно сложнее задачи 2, при этом нам не обязательно решать, сколько времени займёт выполнение каждой из них.

Процесс сравнения всегда основан на опыте конкретной команды. Поэтому оценки каждой команды уникальны.

Как наша команда начала использовать относительную оценку сложности

Нам было сложно перестроиться с абсолютной оценки часов на относительную оценку сложности.

Для начала я описала все параметры сложности во внутренней документации, привела примеры оценки. Мы обсудили это с командой. Далее мы проделали следующее упражнение:

Из прошлого спринта, который мы оценивали в часах, взяли 3 задачи. Мы их уже выполнили, поэтому всё про них знали. Для каждой задачи мы последовательно прошлись по 4 параметрам сложности (зависимости, навыки, коммуникация, согласованность) и дали новые оценки в относительных Story Points. Это было непросто, мы долго обсуждали каждую оценку и приходили к единой цифре. Вот что у нас получилось:

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

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

Результаты перехода на относительную оценку сложности

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

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

Важные результаты для нашей дизайн-команды:

  • прозрачность задач;

  • более точные оценки с меньшими усилиями;

  • команда дизайнеров понимает, что мы должны знать перед выполнением задачи;

  • лучшая декомпозиция задач;

  • учитывается вся работа, включая согласования, генерацию идей и обсуждения;

  • мы постоянно сравниваем задачи и видим общую картину.

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


Больше о проектировании интерфейсов и UX можно почитать в моём телеграм-канале Поясни за UX.

Подробнее..

Перевод Каково работать вместе с очень ужасным разработчиком

20.01.2021 12:12:03 | Автор: admin


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

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

Если я скажу, что тот или иной член команды халтурит, и даже объясню всё вежливо и с техническими подробностями, менеджеры воспримут это как ссору и сосредоточат всё своё внимание на сплочённости коллектива, подразумевая, что проблемы создаю именно я.

Внешние факторы


До недавнего времени я работал в распределённой команде, трудившейся на английскую компанию. Один из членов команды, которого я буду называть Л., не только писал ужасный код (подробнее об этом ниже), но и был в три раза громче всех остальных на ежедневных планёрках в Zoom. Своим пронзительным голосом, не заботясь о правильном английском произношении, он настаивал на том, что ему нужно показать свой экран, но на самом деле не демонстрировал ничего информативного мы просто смотрели, как он двигает курсором мыши.

Он обладал механистическими привычками. Его реакция на любую смену темы была всегда одинаковой. Настала его очередь говорить? Давайте я покажу свой экран. Появилось сообщение об ошибке? Получайте полноэкранный скриншот в BMP с огромным прямоугольником, внутри которого самого сообщения почти не видно. Нужно объяснить ключевое слово? Ещё один скриншот. Спасибо, Л., мы ведь не знали, как пишется foreign key.

Я уже начал бояться созвонов, потому что его пронзительный громкий голос вызывал у меня головную боль. Все остальные члены команды освоили английский в достаточной для понимания степени, а Л. смещал ударения в словах (Chrome conSOLE) и это напомнило мне, почему так много компаний, выведших техподдержку на аутсорс в его стране, теперь переносили её в Филиппины.

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

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

Это никак не связано с акцентом. Я привык к иностранным акцентам. Это просто ещё одно проявление его посредственности.

Он не реагировал на то, что ему говорили и вносил изменения в поведение интерфейсов и API, не сообщая об этом никому. Так как у нас не было ревизий кода (code review), которые я упорно стремился внедрить, мы обнаруживали эти беспричинные изменения, только когда что-то ломалось.

Хуже всего было то, что у Л., похоже, каждые несколько минут происходила когнитивная перезагрузка. В той компании ветки Git были настроены совершенно неправильно две master-ветки для одного репозитория, одна для фронтэнда, другая для бекэнда. Мой код криптографии относился к master-ветке фронтэнда. Мы говорили о ветках с упоминанием их названий примерно десять минут, и было совершенно понятно, что я выполняю мою работу во frontend-crypto, которую мы упоминали много раз.

Внезапно он спросил меня, совершенно не к месту: Крис, а в какой ветке ты работаешь?

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

Плохой код


Обычно я работаю с семейством языков C и в веб-разработке пишу на C#. Мне пришлось выучить JavaScript, Python и Django. В результате теперь я почти исключительно пишу на JavaScript и работаю во фронтэнде. Обычно я бекэнд-разработчик; в том проекте всю работу по бекэнду выполнял Л.

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

Я пишу конечную точку


Мне нужен был новый API, который бы возвращал две или больше строк для получателей, присутствовавших или отсутствовавших в базе данных. Я не знаю Django достаточно хорошо, чтобы сделать это идеально, не понимаю, где заканчивается Python и начинается Django (мне сильно не нравится Django, в нём нет целостности и идиоматичности), но написал всю логику и коды состояний.

Допустим, я прошу этот API поискать ключи шифрования десяти людей. Вот найденное количество и коды состояний HTTP на моём плохом Django:

Возвращённое        Код HTTPколичество10               200 (полный успех)1-9              206 (частичный успех)0                204 (данные не найдены)Ошибка сервера   500 (исключение)

Если ответ содержит меньше строк, чем запрошенное количество, то я возвращал массив их идентификаторов not-found.

Я обратился к Л., чтобы он исправил мой синтаксис Django, но не переписывал логику, и вот что он сделал:

Возвращённое        Код HTTPколичество10               200 (полный успех)1-9              200 (неправильно)0                200 (неправильно)Ошибка сервера   400 (неправильно)

То есть даже если не возвращалась ни единая строка, он называл это полным успехом и он удалил мой массив не найденных строк, поэтому клиенту пришлось бы перечислять возвращаемые данные, сравнивать с запросом и определять, какие из них не были возвращаены. А ошибка сервера возвращала 400, Bad Request, что совершенно неверно.

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

Ради справедливости надо сказать, что существует множество подходов к тому, как обрабатывать промежуточные уровни успешного выполнения действий API. Я почти никогда не видел никаких кодов состояний 2XX, кроме 200; 200 и 500 это единственные коды, которые возвращает большинство разработчиков. Большинство разработчиков знает только три или четыре кода состояний. Л. знал два и один из них был неправильным.

Можно было бы благородно допустить что у Л. есть собственный подход, отличающийся от моего; на мой взгляд, если кодов больше, чем четыре, значит, на то есть причина, и поэтому я их использую. Однако уже проработав с ним несколько месяцев, я был уверен, что он просто скопипастил во все строки одну и ту же, вероятно, взятую с StackOverflow. Он сохранил мою логику фильтрации для всех заданных мной случаев (0, 19, 10), но вставил для всех них одинаковую строку.

Как бы то ни было, API это транзакция, и если он изменил его поведение, то обязан был сообщить остальным о своих изменениях, потому что мы ожидали более подробных кодов состояний. Но он не только этого не сделал, но и никогда не отвечал мне, когда я его об этом спрашивал. Это непохоже на командную работу. Именно так мы всегда с ним и работали. Поскольку у проекта не было QA, то вероятнее всего, первыми дыры в логике увидят клиенты.

Реакция руководства


Я был в гневе. Я сделал всё правильно, за исключением синтаксиса Django, который он бы мог исправить за минуту, но вместо этого он переписал весь код, значительно изменив его логику. И разумеется, его код выглядел так, как будто на клавиатуре подрались два кота.

Я попытался спросить у Л., почему он внёс эти изменения, но когда он как обычно проигнорировал меня, я попросил менеджеров созвониться по конференц-связи. Я показал им то, что я написал сам. Они выразили своё недовольство и сказали, что поговорят об этом с Л. Не думаю, что они с ним говорили, потому что спустя две недели в коде ничего не поменялось.

И этому человеку платили.

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

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

Менеджеры, не знающие кода


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

Вероятно, они восприняли мой отчёт как трения между мной и Л.; я нормально общался со всеми и у меня получалось скрывать своё недовольство Л., его постоянным загадочным забыванием контекста и ужасным кодом. Однако на этом моя часть работы была практически завершена и ситуация никак на меня не повлияла.

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

Но если бы я был руководителем, Л. уже бы искал другую работу.

Этика работы в разработке ПО это спектр, в котором существует два полюса:

  1. Делать всё максимально идеально, и к чёрту все дедлайны
  2. Выполнять минимально возможный объём и сделать своим единственным приоритетом выполнение списка задач. Устранять слабые места написанием юнит-тестов (которых мы не писали).

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



На правах рекламы


У вас могут быть не лучшие коллеги, но за надёжные серверы вам не нужно волноваться. Наша компания предлагает серверы с Linux или Windows. Не экономим на железе только современное оборудование и одни из лучших дата-центров в России и ЕС. Поспешите проверить!

Подробнее..

Перевод Рентабельность инвестиций в Канбан. Часть 1

04.01.2021 12:22:00 | Автор: admin

Они хотят увидеть экономическое обоснование, прежде чем мы сможем приступить к использованию метода?! это слова главы отдела, которую я обучал в рамках запланированного внедрения Канбан. У неё были смелые планы по улучшению показателей своего подразделения, но этот вопрос заставил её задуматься.

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

Дисбаланс окупаемости инвестиций (ROI)

Первые несколько статей о рентабельности инвестиций будут сосредоточены на экономических выгодах от использования Канбан. Как только мы позаботимся о верхней части уравнения окупаемости инвестиций, мы обратим наше внимание на нижнюю половину стоимость реализации. Что касается стоимости реализации, то команда в SquirrelNorth экспериментировала с различными моделями, чтобы обеспечить оптимальную комбинацию обучения, коучинга и консультирования для достижения долгосрочных результатов, о которых я расскажу в заключительных частях этой серии статей. Есть причина рассказать об этом в конце, это связано с большой разницей между инвестиционными затратами и экономическими результатами. Инвестиционные затраты сравнительно небольшая сумма по сравнению с выгодами: не сосредотачивайтесь слишком сильно на знаменателе, числитель вот где происходит самое интересное!

Ранние и непрерывные выгоды!

Канбан-подход это всегда ранние и непрерывные улучшения. Эволюционный подход к изменениям поддерживает существующую производительность организации, в то же время позволяя вносить изменения в процессы, которые открывают возможность быстрого старта улучшений бизнеса. (также он хорошо справляется и с социальными проблемами, которые не затронуты в данной статье)Традиционные подходы к изменениям заключаются в банальной установке нового процесса поверх старого. Такое разрушение старого приводит не только к периоду низкой производительности (потенциально длительному) , но и к выходу производительности на плато без дальнейшего продвижения (даже если цели улучшения достигнуты). Канбан метод позволяет избежать социальных и экономических рисков и даёт результаты на ранней стадии и постоянно наращивает их на протяжении всего его использования; т. е. речь идет о постоянных улучшениях.

Традиционная модель изменений в форме J-кривой в сравнении с моделью изменений Канбан

Ранние формы Канбан

В Канбан методе не существует такого понятия, как правильный Канбан, только применения различных инструментов Канбан, соответствующие разному уровню зрелости организации. Этот подход был систематизирован в модели, известной как Модель зрелости Канбан (Kanban Maturity Model KMM), которая классифицирует организационную зрелость по 7 уровням: от 0 до 6.

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

С учётом этого пути повышения зрелости, большинство внедрений Канбан начинаются с низкого уровня зрелости (уровни от 0 до 1), что раньше до введения KMM называлось Прото-Канбан. Также следует отметить, что большинство организаций так и остаются на этом низком уровне зрелости, если они не вкладывают средства в получение квалифицированной внешней помощи в форме коучинга и обучения (подробнее об этом в следующей статье, посвященной инвестиционной стороне вопроса).
Несмотря на низкую зрелость этих методов, они всё же приносят пользу. Давайте рассмотрим некоторые ранние формы Канбан:

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

Базовая доска, которая по-прежнему дает полезную информацию.

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

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

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

Нам нужно меньше управлять, не сбавляя обороты!

Больше одновременной работы = Больше работы для отслеживания = Больше транзакционных издержек.

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

Outlook Blue всегда полный календарь, которым трудно управлять при бесконечной параллельной работе.

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

Количественная оценка прибыли от внедрения ранних форм Канбан

Наши наблюдения показывают, что при самых скромных сокращениях сверхурочных и транзакционных издержек можно привести к снижению затрат на управление с использованием Канбан на 5-10% в течение 6 месяцев после начала использования Канбан.

Теперь мы можем использовать эту цифру в качестве первой части раздела прибыль для нашего расчёта окупаемости инвестиций. Для примера возьмем ежегодные операционные расходы большого отдела в 20 миллионов долларов, что даёт выигрыш в 1 миллион долларов к концу первого года. Это все равно что получить целую дополнительную команду бесплатно! Это уже вполне ощутимая выгода, имеющая материальную ценность. Что ещё может предпринять организация, высвободив 1 миллион долларов? Отличная новость состоит в том, что до конца года мы успеем ещё больше улучшить зрелость нашей организации и наши практики Канбан метода!

Дальше больше!

В следующей статье я исследую преимущества перехода на уровни зрелости 2+ и дам количественную оценку прибыли от использования Канбан в следующие 612 месяцев.

Подробнее..

У Вас проблемы с legacy значит, Вам повезло! Распил монолита на PHP

06.01.2021 06:14:44 | Автор: admin

Вступление

Меня часто просят рассказать о работе с legacy-монолитами. Про микросервисную архитектуру и переход на нее говорят много, но редко упоминают о том, что проекты приходят ней после многих лет роста с монолитным приложением. Учебники по решению проблем не пишут. Чтобы поменять архитектуру живого решения, надо пройти через несколько этапов. Автор работал с разными проектами - и с полноценным multitenancy service-oriented REST architecture в Oracle, и с огромным монолитом, в репозитории которого были коммиты за десять лет. Эта статья - о темной стороне, о legacy-коде, и практических решениях проблем с монолитными приложениями на PHP.

Причины появления legacy

Есть две основные причины появления legacy-кода.

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

Вторая - технический долг, который создается специально. Руководство сокращает срок разработки ПО за счет отказа от проектирования, автоматического тестирования или code review, одобряет сторонние библиотеки, которые не поддерживаются, а разработчики не документируют сложную логику. Это встречается повсеместно и не зависит от количества денег на счету компании. Не стоит ругать плохих начальников. У них есть весомые причины поступать именно так.

У продуктов есть жизненный цикл, период большого спроса на популярные товары длится три-четыре месяца. Все лучшее конкуренты скопируют и сделают еще лучше, поэтому компании вынуждены регулярно выпускать новинки. Чтобы поддерживать объем выручки, новые продукты и новые версии выпускают каждые несколько месяцев, так продажи нового цикла компенсируют снижение продаж по товарам в конце цикла. По три-четыре крупных релиза в год делают и Apple, и Marvel, и в Oracle на рынке enterprise SAAS тоже квартальный релизный цикл. При этом, рецепта успеха не существует. 97% стартапов выкидывают наработки по своему продукту, и пробуют делать что-то новое, прежде чем найдут такой продукт, который у них покупают. Поэтому затраты на разработку MVP в стартапах максимально сокращают.

У вас проблемы с легаси - значит, вам повезло!

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

Проблемы?

Не всегда плохой код создает проблемы. Например, знаменитый пакет Wordpress написан очень плохим кодом, но на его основе работает 38% интернет-сайтов. Стандартные работы выполняют специалисты на аутсорсинге по прайс-листу, а обновления устанавливаются по нажатию кнопки. Проблемы с Wordpress начинаются, когда в него добавляют нестандартный код, и автоматическое обновление становится невозможно.

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

Что делать тем, кому повезло?

Начинать надо с тестирования

Серьезные изменения кода всегда приводят к неожиданным проблемам. Без надежного тестирования сбои приложения приведут к потере выручки и снижению продаж.

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

Обновление версии языка

Через несколько лет после написания код становится несовместимым с актуальной версией языка, и это приводит к вороху проблем.

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

Составить список проблемы совместимости с новой версией PHP помогут утилиты статического анализа.

Rector поможет решить простые случаи несовместимости с новой версией, автоматически обновив часть кода.

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

Phan показывает использование в коде лексических конструкций, которые убраны из новых версий PHP.

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

Обновление версии платформы или языка в таком случае выполняется достаточно быстро. Автор был инициатором обновления PHP с 5-ой версии на 7-ую для приложения с очень большим объемом кода, и эта задача была успешно выполнена командой за три недели.

Переход от монолита к сервисной архитектуре

Иногда проекты вырастают. Продукты стали успешными на рынке, и регулярно выпускаются. По законам Лемана сложность ПО растёт, функциональное содержание расширяется, вместе с ними штат разработчиков и объем кода постоянно увеличиваются. Замена устаревшего ПО в бюджет разработки не закладывается, чтобы улучшить финансовые результаты, поэтому качество программ ухудшается. Размер git-репозитория может исчисляться гигабайтами. Постепенно скорость разработки уменьшается, и когда разработчики перестают успевать выпускать ПО для новых продуктов, монолит решают разделять.

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

К счастью, слона можно съесть по кусочкам - отделять от монолита модули, не переписывая код заново, зафиксировать API, а затем превращать их в сервисы. Сначала части кода приложения надо выделить в отдельные пакеты, а затем из пакетов можно будет создавать сервисы.

Перенос кода в пакеты открывает ряд возможностей:

  • можно сократить размер репозитория приложения,

  • разработчикам из разных команд можно предоставить только публичный API пакетов, и ограничить вызовы внутренних классов,

  • можно описать зависимости между своими модулями и использовать composer для управления зависимостями и версиями своих пакетов,

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

  • можно выпускать разные версии пакетов, и согласовать изменения API.

Главное - это относительно небольшая по объему работы задача. Вынести часть кода в пакет без переписывания можно за несколько дней. У автора был опыт переноса в пакеты по тысяче строк кода в день с инверсией внешних зависимостей. А после фиксации API модулей будет проще заниматься масштабным рефакторингом.

Разделение приложения на пакеты

Допустим, есть приложение на PHP, которое предоставляет клиентский API. Начинать любые изменения надо с процедур тестирования и релиза, которые включают план отката. Эти процедуры называют release, control, validation и DevOps. В активно развивающихся проектах тестирование и выкладка отработаны. В этом случае надо начинать разделять приложение с определения таких ограниченных контекстов, которые логично выделить в отдельные модули и сервисы.

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

Создание отдельного модуля - это цикл из пяти подзадач:

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

2. Определить API модуля - написать интерфейс, доступный приложению;

3. Написать или проверить приемочные тесты - например, на загрузку и валидацию изображения;

4. Скопировать в модуль старый код и инвертировать в коде модуля зависимости через границу модуля, без рефакторинга или переписывания всего кода;

5. Заменить в коде приложения прямые обращения к старому коду на вызовы сервиса из нового модуля; Для решения этой задачи используется две технологии: IoC-контейнер и менеджер зависимостей.

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

Начать создавать пакеты можно в локальном каталоге, а для полноценной сборки и развертывания стоит создать собственный репозиторий пакетов, такой, как Packeton, и перенести код модулей в собственные git-репозитории. Так же, можно использовать платный репозиторий Private Packagist.

Как создать composer-пакет в приложении и зарегистрировать его как сервис в IoC-контейнере, можно посмотреть здесь: до изменений, после изменений, diff.

В примерах используется composer для управления зависимостями пакетов и Symfony Dependency Injection как IoC-контейнер для сервисов. У Вас может быть другой контейнер. Если в приложении нет IoC-контейнера, придется делать рефакторинг и реализовать внедрение зависимостей. Простейший пример добавления IoC-контейнера в приложение.

Решение проблем со связанностью кода

Есть два типа связанности:

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

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

Рассмотрим случаи связанности кода, и варианты выделения модулей в пакеты без трудоемкого рефакторинга.

1. Расширение классов, реализация интерфейсов, использование трейтов, когда декларация структур используется через границу будущего модуля.

Приведу пример устранения связанности при наследовании, когда родительский и дочерний классы вызывают методы друг друга: результат, diff.

Основные алгоритмы расцепления связанности:

  • Сторонние библиотеки, которые используются в коде пакета, можно указать в зависимостях пакета.

  • Для интерфейсов, которые используются и в пакете, и в приложении, надо создать пакет контрактов, и указывать его в зависимостях.

  • Наследование от внешних классов с зависимостями надо превратить в композицию с помощью адаптеров, которые внедряются как сервисы.

  • Для защищенных свойств, которые используются в дочернем классе, надо сделать getter-методы, а для защищенных методов надо создать прокси-методы.

  • Наследование классов приложения от классов модуля стоит инвертировать в композицию с сервисом, который предоставляется новым пакетом.

Рефакторинг наследования - довольно трудоемкая задача, а добавление адаптеров может негативно повлиять на производительность. Поэтому для небольших родительских классов и трейтов без зависимостей, имена которых не используются в типах параметров, можно нарушить принцип подстановки Лисков, и для сокращения объема работы просто скопировать в пакет, выставив им пространство имен пакета. Пример: до изменений, после изменений, diff.

2. Статические вызовы.

Синтаксис PHP допускает вызов статических методов у объектов как методов класса (пример). Если Вы выносите в пакет или обычную функцию или класс, у которого есть статический метод, эти функции/методы нужно добавить в публичное API пакета (пример, diff).

Аналогично, статические вызовы из пакета к методам классов приложения можно заменить статическими вызовами сервисов. Это будет реализация паттерна мост.

Ссылки: пример прямого статического вызова, пример инверсии зависимости статического вызова через внедрение сервиса, diff коммита.

Если несколько методов из разных классов используются вместе, для них можно создать сервис-фасад.

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

Если есть несколько независимых классов-хелперов (пример) или обычных пользовательских функций, которые используются одновременно и в приложении, и в новом модуле, из них можно создать отдельный composer-пакет, и указать его в зависимостях приложения и других пакетов.

5. Использование глобальных констант и констант классов.

Возьмем пример: в приложении есть класс, который нарушает Single Responsibility Principle, и содержит обращения к константе другого класса. Наша задача - вынести первый класс в пакет без рефакторинга второго класса, потому что рефакторинг потребует изменения всего остального кода, в котором используется константа. Надо избавиться от прямого обращения к константе.

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

Ссылки: до изменений, после изменений, diff, декларация инъекции константы в контейнере.

6. Динамическое разрешение имен через строковые операции.

Пример: $model = new ($modelName . Class);

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

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

Оптимизация

В больших приложениях количество сервисов в IoC-контейнере бывает очень большим. Если в пакет выносится большой объем кода, у него могут быть десятки зависимостей. При обработке клиентских вызовов обычно создается только небольшая часть сервисов. Однако, при передаче зависимостей в конструктор класса контейнер будет создавать все перечисленные сервисы.

Есть несколько способов решения этой задачи:

  1. Сервисы, которые передаются в пакет, можно объявить как lazy.

  2. Объект API пакета можно объявить как Service Subscriber.

  3. Разделить API пакета на несколько сервисов.

Самый гибкий способ - это реализация Service Subscriber. Когда сервис объявляется подписчиком, можно реализовать в пакете вызов внешних сервисов по мере обращения к ним в пакете. Примеры: код до изменений, где используется один из нескольких классов, и код после переноса в пакет c инверсией зависимостей, где нужный сервис создается по требованию. Diff.

Service-Oriented Architecture

Хорошо, разделили код на пакеты, но при выкладке все собирается в одно приложение, и работает в одном процессе, как монолит. А где же сервис-ориентированная архитектура? До нее еще долгий путь.

У каждого пакета зафиксирован публичный API. На основе этого API можно создать сервис с restful-протоколом. Код нового сервиса - это код пакета, вокруг которого написан достаточно стандартный роутинг, запись логов, и прочий инфраструктурный код. А в старом коде вместо кода пакета появляется адаптер для http-вызовов через curl.

При создании отдельных внутренних приложений-сервисов надо решить две задачи:

  1. Детальное протоколирование вызовов всех сервисов. Каждому клиентскому запросу надо присваивать уникальный ID вызова, который передается во все сервисы при вызовах внутренних API, и каждый вызов сервиса надо протоколировать. Надо иметь возможность отследить вызовы сервисов по цепочке.

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

Заключение

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

Подробнее..

Перевод Рентабельность инвестиций в Канбан. Часть 2

08.01.2021 14:08:13 | Автор: admin

Если вы не читали первую часть этой серии статей, сначала прочтите еездесьи возвращайтесь.

Пересмотр преимуществ Части 1

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

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

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

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

Помимо непосредственной команды

Использование Канбан Метода внутри одной команды в течение некоторого периода времени может иногда вызывать у команды мысли вроде: Что если бы люди, которые с нами работают, тоже использовали Канбан?.Это пример раннего осознания того, что в большинстве организаций для выполнения работы необходима поддержка других людей. По сути, работа должна переходить от одной команды к другой. Если цель стоит в сохранении непрерывного потока работы в компании, то взаимодействие команд друг с другом очень важно!Обычно мы видим это в двух сценариях.В процессе работы:

Переход с одного этапа на другой:

Получается, что задача в статусе Выполнено для одной команды, для другой команды является задачей в статусе Нужно сделать. Эту ситуацию можно визуализировать с помощью шаблона доски которая называется Агрегированный командный Канбан (Aggregated Team Kanban). При таком подходе на одной доске отображаются две или более досок команд, чтобы лучше понять задержки при координации.

Использование Канбан в разных командах дает ряд преимуществ:

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

Сотрудничество между командами аналогично, как в первой статье, при сотрудничестве между отдельными членами команды, совокупное представление даёт возможность командам работать совместно. Это приводит к тому, что несколько команд работают так, как если бы они были одним целым.

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

Бизнес-преимущества видимости и сотрудничества между командами

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

Таким образом, бизнес-результаты можно представить в трёх дополнительных категориях:

Увеличение пропускной способности.Пропускная способность объём завершенной работы, а не количество задач со статусом В работе. С уменьшением количества застрявших задач количество работы со статусом Выполнено начинает увеличиваться. Наблюдая за использованием Канбан Метода на этом уровне от 6 до 12 месяцев, мы видим удвоение пропускной способности!

Сокращение времени вывода продукта на рынок благодаря сокращению задержек, время, необходимое для создания продукта сокращается. На этом уровне использования Канбан сокращение времени выполнения заказа составляет от 10% до 50%. Например, если раньше на выполнение чего-либо требовалось 30 дней, то теперь это займет от 15 до 27 дней.

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

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

Итак, мы имеем отдел стоимостью 20 млн долларов с доходностью 10%, вот где мы находимся на данный момент:

Итого:мы видим выгоду размером 4,7 млн долларов, благодаря усовершенствованиям процессов. Рост выручки основной источник выгод.

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

В следующих статьях мы увидим, как этот набор преимуществ сохранится и будет расти по мере повышения зрелости организации!

Подробнее..

Использование GitHub в обучении. Примеры. Часть III

09.01.2021 20:18:44 | Автор: admin

Продолжу выкладывание примеров использования GitHub'а как инструмента обучения.


Предыдущий пример

Вариант командной работы с несколькими репозиториями

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

Примерный порядок действия

Часть действий повторяются из предыдущего примера

  • Создаёте аккаунт организации

  • Добавляете в него студентов.

  • Создаёте репозиторий. В README.md добавляете текст задания. Также наполняете репозиторий предварительно необходимым минимумом (нужными файлами для выполнения задания). Создаёте необходимые ветви. Обычно создаю ветвь dev или develop

  • Студенты получив задания, клонируют репозиторий себе на локальные машины.

  • По мере обсуждения решения выявляются подпроекты. Создаются команды под каждый подпроект. Для каждого подпроекта создаётся свой репозиторий с предварительным наполнением.

  • Команды выполняют задания, коммитят, пушат. Задания можно выдавать как черезissues, так и какой-нибудь сервис с Kanban или Scrum

  • Создают запрос на слияние

  • Проверяете. Оставляете комментарии либо ко всему заданию целиком, либо к его отдельным частям.

  • Создаются релизы. Готовые DLL или ещё что берётся из релизов и подключается в основной проект.

  • В каждой команде ведётся техдокументация.

Плюсы и минусы

Плюсы:

  • Более приближенный к реальности вариант моделирования

  • Можно назначать студентов в качестве ревьюеров кода. Даже преподавательского.Я люблю делать в коде специально ошибки как явные, так и неявные, чтобы студенты их находили и исправляли.

  • Каждая команда работает над своим подпроектом

  • Студенты пробуют межкомандное взаимодействие при разработке одного большого проекта.

Минусы:

  • Нужно создавать отдельный аккаунт для организации

  • Нужно объяснить как работать с ветками и следить, чтобы пушили в нужную ветку.

  • Нужно объяснять что такое релиз, как происходит версионирование.

  • Нужно объяснять как пишется и для чего нужна техдокументация.

Какие можно внести дополнения:

  • связать репозиторий с Kanban- или Scrum-сервисом, чтобы выдача заданий фиксировалась в карточках на досках

  • создавать не отдельные репозитории для каждого подпроекта, а использовать gitsubmodules

Подробнее..

Как я стал PMP, не выпив ни одного кофе

16.01.2021 18:16:46 | Автор: admin

План

Всем привет, меня зовут Максим!

В начале 2020 года я решил сконцентрироваться на проектах по разработке программного обеспечения и перешел на позицию руководителя IT проектов в банк.

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

План был такой:

1. весной я изучаю практики Банка по проектному управлению;

2. летом читаю книги и статьи по управлению проектами;

3. осенью готовлюсь и сдаю.

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

В июне я перенес коронавирус и больничный позволил прочесть пару лишних книг.

Для финальной подготовки и сдачи я планировал отпуск 2-3 недели в октябре-ноябре, но отпуск в 2 недели получилось взять на месяц позже в ноябре-декабре.

Сдал я 28 декабря 2020 года.

Теперь немного подробнее о подготовке и сдаче.

Книги

Летом я прочитал несколько классических книг по управлению проектами:

Питер Друкер - The Effective Executive;

Фредерик Брукс - Мифический человеко-месяц;

Фергус ОКоннел - Как успешно руководить проектами; Серебряная пуля;

Том Демарко - Deadline;

Джефф Сазерленд - Scrum.

Каждая книга по своему хороша и отражает взгляд автора на те или иные проблемы менеджеров и менеджмента.

PMBOK 6 (Руководство к своду знаний по управлению проектом) я прочитал 2 раза - на русском и английском.

Вообще читать PMBOK в первый раз очень тяжело, но во второй раз он стал намного понятнее, а теперь я даже могу применять его в работе.

Курсы

Летом я начал смотреть видеоролики на Youtube, я пересмотрел много русских и английских, могу порекомендовать следующие:

Основы PMBoK (5-th edition) от Ивана Селиховкина, - достаточно хороший обзорный курс, который не еще утратил актуальности;

PMP Exam Prep Course от Boston Management Consulting International - очень подробно рассматриваются процессы PMBOK 6.

Я давно хотел опробовать Linkedin Learning и там как раз оказались нужные мне курсы, а учитывая, что Linkedin Learning является авторизированным партнером по обучению PMI, я понимал, что с принятием сертификата проблем не будет.

Правда курсы на английском языке, но с ним у меня нет проблем.

Первый месяц бесплатно, чем я и воспользовался, просмотрев в октябре 2020 серию видеокурсов по управлению проектами:

Project Portfolio Management Foundations

Learning Program Management

Project Management Foundations: Ethics

Cert Prep: Project Management Professional (PMP)

Cert Prep: PMI Agile Certified Practitioner (PMI-ACP)

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

Больше всего мне понравились курсы по этике по Кодексу профессиональной этики и поведения PMI и управлению портфелем - наверное потому что эти темы были самые новые для меня.

Полный перечень курсов для различной сертификации здесь.

Тесты

Для подготовки я использовал несколько приложений и сайтов.

Я попробовал с десяток разных приложений но пользовался следующими:

PMP EXAM Mentor - содержит словарь, формулы, советы, краткое описание процессов, техник, входов-выходов;

PMP Certification Exam 2020 - 1600 вопросов, сгруппированных по областям знаний, достаточно качественные вопросы, рейтинг ведется по областям знаний, что позволяет - я покупал платную подписку на 3 недели - 2$ в неделю;

PMP Exam Prep 6th edition - тоже очень хорошие вопросы, но мне не понравилась группировка по группам процессами.

Веб-сайты:

Симулятор экзамена PMP Школы управления Алексея Минкевича - один из немногих ресурсов, доступных на русском языке - 400 вопросов;

Oliver Lehmann (Online) PMP Exam Self-Assessment Test - 100 вопросов;

Simplilearn Free PMP Mock Exam - 200 вопросов;

PM Prepcast Free PMP Exam Simulator - 100 вопросов - насколько я понял один из самых популярных симуляторов;

Я специально проходил тесты на разных ресурсах, чтобы узнать вариации вопросов.

За ноябрь-декабрь я прорешал где-то 3000 вопросов, вопросы помогают лучше понять PMBOK, потренироваться быстро отвечать и подготовиться к экзамену.

Процент сдачи тренировочных тестов был 80%+/-5%. После сдачи тестов я просматривал PMBOK по вопросам, которые ответил неверно.

Иное

Видео как заполнять заявление;

Интервью со сдавшими экзамен - помогает зарядиться позитивом и оценить свой ход подготовки;

Топик PMP на REDDIT - истории успехов и фейлов, обмен мнениями;

Telegram каналы:

Project Management Books (PrMaB) - книги, советы, вопросы;

Project Management Club - интервью.

Edward-designer.com - сайт с советами по сдаче экзамена;

PMBOK Process Explorer - сайт с группировкой и кратким описанием процессов, техник, входов и выходов.

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

Потом я сделал 4 таблички (Процессы, Техники, Входы-выходы, Советы) в которые вносил информацию. Работать с табличками мне оказалось гораздо удобнее и привычнее.

Экзамен

Заявление на экзамен я подавал в ноябре, оно прошло без аудита - нужно описать три года опыта управления проектами максимально используя термины PMBOK.

Сдавал я в центре тестирования IBA в Минске.

Сдавать хотел в понедельник после подготовки на выходных, понедельник 21 был занят, а 28 свободен - на этот день я и назначил.

На экзамене я брал перерыв после 90 вопросов.

Экзамен занял где-то 3,5 часа - 3 часа на вопросы и полчаса на проверку.

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

Все группы процессов я сдал с отметкой (AT) Above Target (Выше цели).

С января 2021 экзамен изменился, теперь около половины экзаменационных вопросов будет посвящено предиктивным подходам к управлению проектами, а остальные вопросы будут касаться гибких (agile) или гибридных подходов.

Итог

Если подвести итоги, сертификация PMP заняла примерно 4 месяца (сентябрь-декабрь) и 400 часов, из них 200 часов в последний месяц и стоила мне 550$.

Этап подготовки

Срок

Стоимость

Чтение PMBOK

1 месяц (~100 часов)

139$ - членство в PMI

Курсы, видео, статьи

1 месяц (~80 часов)

0$

Заполнений всех заявлений

3 дня (~10 часов)

405$ - экзамен

Тесты и подготовка

2 мес (~200 часов)

6$ - приложение с тестами

Экзамен

1 день (6 часов)

0$

ИТОГО

4 мес (400 часов)

550$

Сертификация позволила мне структурировать знания в управлении проектами.

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

Управление проектами меняется в сторону гибких и гибридных подходов. Их я тоже применяю с 2014 года, когда начал работать по Scrum.

Что дальше? Наверное Scrum!

Хотя если честно я бы был безумно счастлив попасть в компанию в которой применяется управление проектом, так как это описано в PMBOK.

Кофе

Почему я не пил кофе?! - после коронавируса в августе у меня обострился гастрит, так что кофе и энергетики я не принимал - только здоровый сон. К декабрю все нормализовалось, но кофе я пока не пью - только зеленый чай.

Всем здоровья и успехов!

Подробнее..

Статистика сертификации Института управления проектами (PMI) в России на 10.01.2021

17.01.2021 22:08:31 | Автор: admin

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

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


Итак, по состоянию на 10 января 2021 года, в открытом реестре PMI числится 1978 сертификатов и 1893 уникальных человека. Важно уточнить, что это количество людей, указавших своим местом жительства РФ и имеющих активный сертификат (он может быть не активен 1 год), не скрывшие их в настройках.

На сколько состав изменился?

Так как данные персонифицированы, то путем сложных математических вычислений мы получаем следующую картинку:

Состояние сертификатов Состояние сертификатов

Продлено 1753 профессиональных сертификата, получено 342 новых, а также примерно 43 старых сертификата возобновлены и приостановлено действие (надеюсь, что временно) примерно 180 сертификатов.

Число возобновленных и приостановленных сертификатов указано примерно, так как данные по старым годам еще не набрались в достаточном объеме, чтобы уверенно называть эти числа.

Что касается изменений по годам, то картинка меня огорчила.

Сертификаты по годамСертификаты по годам

Увы, но не все, кто получил статус в 2000 и 2001 году его поддерживают. И хочется искренне надеяться, что это связано с тем, что просто забыли.

Изменения старых лет с прибавлением связаны со спецификой реестра. Или человек открыл данные, или же его статус был на паузе (по прошествии трёх лет в случае, если вы не выполнили требования для продления статуса, Вам дается год на его обновление. Не успели сдавайте экзамен снова).

Наибольшие потери среди тех, кто сертифицировался 3 и 6 лет назад (цикл и два соответственно у PMI для сертификатов действует трехлетний цикл обновления).

Всего за 2020 год получено 339 сертификатов (и в подборку даже попали 3 сертификата, полученных в 2021 все три сертификата в этот раз отличаются от прошлогодних в этот раз это PMI-ACP, один из которых получил автор). В 2020 году получили:

в первом квартале 72 сертификата;

во втором квартале 46 сертификатов;

в третьем квартале 75 сертификатов;

в четвертом квартале 150 сертификатов.

И прибавка последнего квартала связана с изменением экзамена PMP, с 2021 года он обновлен и достаточно сильно (пусть пока в рамках PMBoK 6).

За этот год прибавилось:

15 CAPM;

299 PMP;

18 PMI-ACP (или 21 с учетом получивших сертификаты в 2021 году);

2 PMI-PBA;

5 PMI-RMP;

1 PgMP;

3 PfMP.

У нас на сегодня все так же всего 1 человек, обладающий 4 сертификатами. Обладателей 3 сертификатов стало 5, против 3 в прошлом году. И один из них стал первым в РФ членом малочисленного клуба обладателей PMP, PgMP и PfMP это Антон Субчев.

Людей, обладающих двумя сертификатами стало 74.

Результаты 2019 и 2020 годаРезультаты 2019 и 2020 года

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

И в заключение несколько традиционных графиков по имеющимся данным.

Spoiler

Пирог сертификатов PMI

Динамика прироста PMP

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

Подготовлено на основании открытых данных, размещенных на портале PMI.ORG

Михаил Белов, PMP, PMI-ACP, ICP-ACC

PRINCE2 Foundation, PRINCE2Agile Foundation, ITIL4Foundation certified

Подробнее..

Digital-трансформация завода CRM для ERP, роботизация БП и оживление железа, ЛК, чат-боты и dream team (ч. 1)

18.01.2021 12:13:17 | Автор: admin

Часть 1: CRM для ERP (в этой публикации)

Часть 2: Роботизация бизнес-процессов и оживление железа

Часть 3: Личные кабинеты, чат-боты и dream team

Текущий уровень автоматизации: 2 года назад

Ситуация на момент моего прихода в компанию на должность CIO:

  • Коротко о заводе: круглосуточное производство, круглосуточная отгрузка продукции

  • Необновляемая с 2014 года ERP 2 и платформа 1С, пресс-релиз о внедрении

  • Бизнес-процессы компании, оторванные от бизнес-процессов в ERP, и как следствие:

    • Параллельная вселенная в виде файлов Excel, Google-таблиц и облачных хранилищ

    • Присутствие журналов и реестров для ручного заполнения сотрудниками

    • Много бумажного документооборот, в т.ч. с контрагентами

  • Минимум данных в ERP-системе и исторические "костыли" в разработке

  • Скромный сайт компании без какого-либо функционала и интеграций

  • Штат ИТ не укомплектован, процессы в дирекции толком не выстроены

  • Огромный список "зависших" текущих задач, начиная с 2016 года

  • Поддержка: 2 сисадмина и 1 помощник, консультант 1С и консультант-программист начального уровня на ГПХ

  • Один договор с одной местной компанией "1С:Франчайзи" на оказание услуг

  • Авральный режим работы пользователей и бесконечное "тушение" пожаров службой ИТ

  • Большое желание руководства компании выйти на новый уровень автоматизации

Первая smart-задача: "сделать CRM за 3 месяца!"

Мои попытки уточнить детали задачи, ее рамки и требуемые результаты - не увенчались успехом. В коммерческой дирекции ассоциации с CRM были весьма размытые, опыта никто не имел.

К счастью, с CRM-системами я был хорошо знаком

Еще с 2016 года, когда я был руководителем проектов внедрений в ИТ-компании, у меня уже были клиенты, которым мы продавали и настраивали 1C:CRM.

В 2018 году я возглавил новое направление в этой же ИТ-компании по внедрению популярных CRM-систем (1C:CRM, amoCRM, Битрикс24.CRM).

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

"Коробочная" CRM для исторической ERP: это реально!

Неожиданная новость: у нас уже заключен договор на разработку CRM

За 2 месяца до прихода в компанию, мой предшественник заключил договор на разработку CRM-системы (именно разработку новой CRM "с нуля", а не внедрения существующих).

Ко мне на встречу пришел программист 1C, который выполнял разработку CRM-системы для нашей ERP, чтобы сдать проект и подписать акт.

Тщательный аудит и проверка работ на соответствие ТЗ показала, что это была попытка "срубить бабла". Фактически в ERP была включена функциональная опция встроенной подсистемы CRM (набивалка) и настроены статусы документа "Сделка" в качестве "воронки" продаж.

Самое интересное, что ТЗ было написано подрядчиком и весьма не плохо, но до разработки так и не дошло.

Договор был расторгнут по причине невыполнения ТЗ.

Далее по совокупности критериев, здравого смыла, и сохранения режима "одного окна" в ERP для менеджеров по продажам - принято решение встроить "коробочный" модуль 1C:CRM 3.

Первая сложность: актуальный модуль 1C:CRM 3 подходил только для ERP 2.4, а у нас редакция 2.1.

Вторая сложность: историческая ERP сильно кастомизирована, местами очень "криво".

Третья сложность: никто из подрядчиков не соглашался выполнять эту задачу, по вышеуказанным причинам.

Лайфхак: Facebook спешит на помощь

Мой 12-летний опыт внедрения различных конфигураций 1С говорил о том, что эти сложности решаемые, и модуль можно интегрировать с ERP.

Хотя подобных кейсов в интернете и на технических форумах я не нашел, обратился к разработчикам через партнерскую группу в Facebook:

  • Разработчики честно ответили, что на их практике такого не было, но гипотетически это возможно, если перенести часть БСП из ERP 2.4 в ERP 2.1 (после чего попробовать интегрировать сам модуль).

  • Один из партнеров с Украины ответил положительно. На их практике было 2 успешных внедрения, когда они встраивали модуль 1C:CRM 3, только в ERP 2.2.

Скриншоты переписки из Facebook я отправил по email потенциальным подрядчикам, и один из них согласился выполнить работу.

Через месяц модуль 1С:CRM 3 был встроен в нашу ERP 2.1.

Еще месяц ушел на интеграцию CRM с почтой, офисной АТС в "облаке" и сервисом отправки SMS.

Еще около месяца ушло настройку новой подсистемы, "воронки" продаж, портрета клиента, обучения менеджеров по продажам.

Smart-задача выполнена в срок.

После запуска в эксплуатацию, CRM получила развитие:
  • Новый сайт компании, интегрированный с ERP (подробнее во второй части)

  • Интеграция ERP с Wialon и ЭТРАН

  • SMS-робот и Email-робот

Ноу-Хау: Самый краткий CRM-отчет для оценки KPI

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

Отчет в CRM для оценки KPI менеджеров по продажамОтчет в CRM для оценки KPI менеджеров по продажам
  1. По данным ERP

  2. По данным звонков и писем с контактным лицам клиентов в CRM

  3. По данным CRM

  4. По данным звонков, сайта и почты в CRM

  5. По данным ERP

  6. По данным ERP

  7. По данным CRM

  8. По данным CRM

Внимание!

С появлением этого отчета, менеджеры тщательно проверяли в нем данные, чтобы не был потерян ни один звонок, ни одно письмо.

Этот отчет мотивирует менеджера по продажам:

- Поддерживать актуальную контактную информацию по всем клиентам.

- Звонить и вести переписку с клиентами с корп. SIM и корп. почты.

- Добиться от ИТ, чтобы CRM работала корректно.

Факты: Фиксация всех входящих и исходящих звонков в ВАТС и CRM

Связка "ВАТС + номер 8-800 + корп.SIM + Софтфон + CRM" иногда сбоила и некоторые звонки не фиксировались. Для решения всех проблем с корп.SIM и номером 8-800 потребовалось около трех месяцев плотной работы с саппортом Мегафон и Рарус.

Мы добились выпуска нескольких обновлений и 100% фиксации звонков в CRM.

Все звонки в ВАТС (8-800, корп. SIM, офисная АТС)Все звонки в ВАТС (8-800, корп. SIM, офисная АТС)Все звонки в CRM (входящие, исходящие, пропущенные)Все звонки в CRM (входящие, исходящие, пропущенные)
Пример: Воронка продаж, портрет клиента, потенциальные сделки

Основные инструменты менеджера по продажам в CRM для работы с клиентами:

Портрет клиента в CRM (детальный)Портрет клиента в CRM (детальный)Воронка продаж в CRM (канбан менеджера)Воронка продаж в CRM (канбан менеджера)Потенциальная сделка в CRM (история взаимодействий)Потенциальная сделка в CRM (история взаимодействий)

Мы также нашли способ автоматической фиксации фактов встреч менеджеров с клиентами в CRM по данным GPS и мобильной сети (не реализовали только из-за отсутствия полноценного API со стороны сервисов, а ручной режим нам не нужен).

Ниже пример стандартных отчетов в CRM:

Анализ источников привлечения клиентов
Анализ источников привлечения в CRMАнализ источников привлечения в CRM
Причины потерь потенциальных сделок (клиентов)
Анализ потерь интересов в CRMАнализ потерь интересов в CRM

SMS-робот и Email-робот для автоматических уведомлений

Модуль 1C:CRM для ERP уже содержал в себе функционал для подключения к SMS-провайдеру и электронной почты, поэтому мы реализовали только автоматические уведомления по SMS и Email, и интеграции с другими сервисами:

  • Клиентов об отгрузке продукции со складов в автомобили и вагоны (через интеграцию ERP с промышленными весами, подробнее во второй части).

  • Клиентов об убытие машины с территории завода со ссылкой-треком для отслеживания на карте (через интеграцию ERP с Wialon).

  • Клиентов о приближение машины у пункту разгрузки (через интеграцию ERP с Wialon).

  • Клиентов о прибытие вагонов на ЖД станцию для выгрузки (через интеграцию ERP с ЭТРАН).

  • Клиентов о необходимости разместить заказ (по расписанию для контактного лица).

  • Менеджеров по продажам о новых заявках клиентов, поступивших в нерабочее время.

  • Клиентов на самовывозе и перевозчиков - об опоздании водителей на погрузку (через интеграцию ERP с чат-ботом и уличным монитором, подробнее во второй и третьей части).

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

  • Перевозчиков о штрафах по опозданиям на погрузку и выгрузку (через интеграцию ERP с Wialon).

Как выглядят сообщения SMS-робота в ERP
СМС-робот в ERP для уведомленийСМС-робот в ERP для уведомлений

Все SMS отправляются с символьного имени, от лица компании.

Как выглядят письма Email-робота в ERP

Письма с вложениями и без:

  • Вложения - это отчеты в формате Excel, автоматические сформированные в ERP.

  • Формы отчетов Excel сразу адаптированы для печати на принтере.

  • Тексты писем адаптированы для чтения в смартфоне и ПК.

  • Письма в ERP синхронизованы с почтовым сервером.

Почтовый робот в ERP для уведомленийПочтовый робот в ERP для уведомлений

Интеграция ERP с Wialon: автоматический сбор данных по GPS

  1. Изначально, стояла задача реализовать автоматическое уведомление клиентов о статусе доставки продукции в режиме онлайн.

  2. Затем мы расширили интеграцию с Wialon и начали использовать сервис для автоматического фиксирования фактического времени прибытия машин на выгрузку.

Это набор готовых сервисов, связанный в единую подсистему. Срок реализации 2 месяца.

Пример SMS-сообщений показан на скриншоте выше.

Схема интеграции сервисов и данных для SMS-уведомлений клиентов о статусе доставки продукцииСхема интеграции сервисов и данных для SMS-уведомлений клиентов о статусе доставки продукции

Забегая вперед, мы также используем уведомления в чат-бот Telegram (подробнее в третье части). SMS - потому что не у всех контактных лиц клиентов есть доступ в интернет на адресах доставки, а мобильная сеть какая-никакая есть практически всегда.

Пример автоматического отчета для контроля прибытия машин на погрузку и выгрузку

На скриншоте отчет, а в ERP это целая подсистема с автоматической рассылкой уведомлений переводчикам о штрафах по опозданиям машин сверх допустимого договором лимита (подробнее во второй и третьей части).

Такая система, в связке с личным кабинетов перевозчика и чат-ботом для водителей (подробнее в третьей части):

  • Дисциплинирует перевозчиков и водителей соблюдать сроки погрузки и доставки

  • Повышает лояльность клиентов и гарантирует своевременные поставки точно в срок

Спасибо, что дочитали до конца!

Задавайте вопросы, постараюсь на все ответить.

Подробнее..

Перевод Почему инженеры не могут оценить время разработки

19.01.2021 12:23:47 | Автор: admin

Статистический подход к объяснению ошибочных дедлайнов в инженерных проектах



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

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

Общая информация


Давайте сначала взглянем на проблему, её последствия и потенциальные первопричины с высоты птичьего полёта.

Проблема


Программные проекты редко укладываются в дедлайн.

Последствия


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

Известные причины


  • Неправильная оценка времени (основная тема этой статьи).
  • Нечётко сформулированные на старте проекта требования с их последующим изменением.
  • Украшательства: слишком много внимания уделяется деталям, не относящимся к сути проекта.
  • Недостаточно времени уделено этапу исследований и проектирования архитектуры. Или наоборот уделено слишком много времени.
  • Недооценка потенциальных проблем интеграции со сторонними системами.
  • Стремление сделать всё правильно с первого раза
  • Параллельная работа над слишком большим количеством проектов или отвлечение (слишком частое прерывание потока).
  • Несбалансированное соотношение качества и производительности.

Чрезмерный оптимизм, эффект Даннинга-Крюгера, чистая неопределённость или просто математика?



Пятая стадия: ПРИНЯТИЕ.

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

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

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

Существует ли в этом безумии методика? На самом ли деле это самый лучший способ решения задач? Я не думаю, что это так, поэтому решил отправиться на поиски рационального математического объяснения тому, почему все эти умные люди не могут оценить время, которое понадобится им на выполнение работы.

Это просто математика!



Однажды я выполнял задачу, которая должна была занять 10 минут, но в конечном итоге потребовала 2 часа. Я начал размышлять о том, почему решил, что она должна занять 10 минут, и как это число выросло до 2 часов. Мой мыслительный процесс был довольно интересным:

  • Я считал, что это займёт 10 минут, потому что в голове на 100% знал код, который нужно написать.
  • Написание кода и в самом деле потребовало примерно 710 минут. А потом потребовалось 2 часа из-за совершенно неизвестного мне бага во фреймворке.

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

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

Здесь нам нужно провести границу между одиночной задачей, нерепрезентативной для всего процесса, и наоборот.

Как мы оцениваем время в нормальных условиях



Нормальное распределение (гауссиана)

Нормальные распределения встречаются повсеместно и человеческий мозг хорошо с ними освоился. Мы специалисты в оценке процессов, по своей природе следующих нормальному распределению; это основа получения знаний из опыта.

Если в этом месяце вы ходили в ближайший магазин почти 20 раз и каждый раз путь занимал 5 минут, за исключением случая, когда сломался лифт и вам пришлось прождать 10 минут, а ещё того случая, когда вы решили подождать две минуты, пока закончится дождь. Сколько по вашим оценкам понадобится времени, чтобы добраться до магазина прямо сейчас? 5 минут?

Я имею в виду, что не имеет смысла говорить 15 минут, потому что это редкий случай, или 7 минут, если только на улице нет дождя. И с большой вероятностью вы окажетесь правы. Если в 18 из 20 случаев путь занимал 5 минут, то определённо существует высокая вероятность, что он займёт 5 минут (медиана) и на этот раз. Вероятность примерно равна 90% (если, разумеется, не вдаваться в более сложные вычисления).

Но график искажён!


Даже если вы хорошо умеете оценивать время на выполнение задачи, это не значит, что вы хорошо оцените время на завершение проекта! Это контринтуитивно, но вы можете ошибиться сильнее.

Все читающие статью нерды-математики (и дата-саентисты/статистики) уже должны были узнать в крошечном графике из предыдущего мема скошенное вправо нормальное распределение. Увеличим его и объясним, что оно означает:


Для этой отдельной задачи медиана (median) по-прежнему имеет более высокую вероятность, чем среднее (mean)! Если вы попытаетесь угадать значение моды (mode), имеющей наивысшую вероятность, то при увеличении объёма задачи ошибётесь ещё сильнее

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


Уравнение задержки на основании этой гипотезы

Задачи программирования в проекте обычно довольно похожи друг на друга или, по крайней мере, сгруппированы в несколько похожих кластеров! Из этого уравнения также следует, что эта проблема масштабируема! Хоть мы и хотим, чтобы всё в программных проектах было масштабируемым, проблемы явно не приветствуются.

Как же воспользоваться этим знанием?


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

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

  1. Проще сказать, займёт ли задача X больше/меньше/столько же времени по сравнению с задачей Y, чем точно определить, сколько займёт их выполнение. Так получается, потому что если скошенность кривых приблизительно одинакова (что справедливо для похожих задач), то сравнение медиан даёт примерно такие же результаты, как и сравнение средних.
  2. Я не запоминаю и не записываю каждую отдельную задачу, чтобы проводить вычисления и получать среднее (и не могу найти никаких данных для таких опытов). Поэтому я обычно оцениваю неизбежную погрешность (среднее-медиана) как процент от времени на задачу, который увеличивается/уменьшается в зависимости от того, насколько я освоился со средой разработки. (Нравится ли мне этот язык/фреймворк (40%) Есть ли у меня хорошие инструменты отладки? (30%) Хороша ли поддержка IDE? (25%) и т.д.).
  3. Я начал разделять спринты на задачи равного размера чтобы обеспечить некую однородность процесса оценки времени. Это позволяет мне воспользоваться пунктом 1. Бывает легко определить, что две задачи примерно равны по времени. Кроме того, это делает задачи ещё более похожими на то, к чему применима гипотеза, и всё становится более предсказуемым.
  4. Применив эти принципы, при наличии ресурсов можно организовать тестовый прогон. Например, если за X1 дней Y1 разработчиков выполнило Z1 однородных задач, то мы можем вычислить X2 (дней), зная Y2 (количество имеющихся разработчиков) и Z2 (общее количество оставшихся задач).




На правах рекламы


Эпичные серверы для разработчиков и не только! Недорогие VDS на базе новейших процессоров AMD EPYC и NVMe хранилища для размещения проектов любой сложности, от корпоративных сетей и игровых проектов до лендингов и VPN.

Подробнее..

Как приоритизировать продуктовые гипотезы на основе юнит-экономики разбираем примеры

19.01.2021 14:16:27 | Автор: admin

Дел у менеджеров по продукту всегда больше, чем ресурсов. Новые задачи приходят со всех сторон от дизайнеров до маркетологов и CEO. Но если брать в работу все подряд, есть риск получить на выходе не то, что нужно для развития проекта, а то, что было по фану кому-то из коллег. Так, сооснователь KISSmetrics Хитен Ша признался, что его компания потеряла позиции на рынке именно из-за ошибок приоритизации. Как только у него появлялись новые идеи, подчиненные должны были бросить все и начать работу над ними. О вдумчивом распределении сил речь тогда не шла. Пока команда пыталась успеть за руководителем, конкуренты захватывали рынок и выпускали новые продукты.

Расскажем, как не допустить такого развития событий с помощью простых методик для приоритизации гипотез. Вообще говоря, эту тему часто поднимают на профильных конференциях и семинарах. Так, Мэтт Билотти, менеджер продукта в Drift, интерактивной маркетинговой платформы, которая заняла шестое место в рейтинге самых быстрорастущих компаний по версии Deloitte, поделился на Epic Growth SEASONS своим взглядом на то, как можно приоритизировать гипотезы на основе юнит-экономики. Он объяснил, в чем преимущества подхода и как его можно использовать в работе.

Источник: unsplash.comИсточник: unsplash.com

Метод оценки задач ICE и его соседи

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

Такой метод оценки называется ICE влияние (Impact), уверенность (Confidence), усилия (Effort). Он был придуман Шоном Эллисом, автором термина Growth Hacking. Преимущество подхода в его простоте: чтобы оценить задачу, достаточно присвоить значения от одного до десяти для каждого из факторов и вычислить ICE Score:

ICE Score = Impact*Confidence*Effort.

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

В отличие от него, так называемый RICE охват (Reach), влияние (Impact), уверенность в оценке (Confidence), трудозатраты (Effort) более сбалансирован.

RICE Score = (Reach*Impact*Confidence) / Effort.

Чтобы оценить фактор охвата, нужно рассчитать количество пользователей, которому придется столкнуться с изменениями в продукте. Фактор влияния обычно отражает ценность, которую фича приносит продукту. Для количественного выражения влияния используют шкалу множественного выбора (это такая модель выбора, когда нужно принять одно решение, но выбрать между тремя и более вариантами):

  • 3 массовое влияние;

  • 2 высокое;

  • 1 среднее;

  • 0,5 низкое;

  • 0,25 минимальное.

Оценка фактора уверенности всегда вызывает много вопросов. Если остальные показатели можно оценить достаточно точно, то как оценить уверенность? И как снизить субъективное влияние в процессе утверждения приоритетов? Можно использовать диаграмму Итамара Гилада, бывшего продакта в Google и Microsoft. На ней можно увидеть описание типичных фактов, на основе которых обычно рассчитывают значения параметра Confidence (личное мнение, экспертная оценка, идея коллеги, фича конкурента, результаты UX исследований, данные на основе интервью и др.). Предположим, ваша уверенность в успехе фичи основана на мнении кого-то из членов команды или личном мнении. Оценка этого фактора в таком случае будет около нуля.

Гипотезы, основанные на данных маркетинговых исследований, запросах пользователей, результатах юзабилити тестов получат низкий уровень уверенности (от 1 до 3). Если же вы, расставляя приоритеты задачам, делаете выводы на основе длительных исследований поведения пользователей, результатов запуска MVP, A/B-тестов и других достоверных данных, уровень уверенности может быть средним (от 3 до 7).

Источник: unsplash.comИсточник: unsplash.com

Вообще говоря, есть много разных подходов для приоритизации задач, все зависит запросов и целей команды. Какие-то компании даже придумывают свои методы. Так, в Netflix используют DHM-подход, в котором гипотезы оценивают по трем критериям:

  • D delight;

  • H hard to copy;

  • M margin.

На практике это означает, что нужно задать ряд вопросов относительно каждой гипотезы. Например, принесет ли прибыль ввод этой фичи? Будут ли пользователи удовлетворены изменениями? Насколько сложно будет конкурентам скопировать этот функционал? Для того, чтобы Netflix начали тестировать гипотезу, она должна соответствовать как минимум двум критериям DHM-модели, а лучше всем трем.

Источник: unsplash.comИсточник: unsplash.com

В блоге Ducalis.io мы нашли классную схему, в которой можно выбрать фреймворк для приоритизации исходя из запросов конкретно вашей команды. Помимо уже известных ICE, RICE, DHM, есть и другие подходы: REAN метод (Reach, Engage, Activate, Nurture), приоритизация на основе North Star метрики, матрица усилий (Effort Matrix), AARRR скоринг и др.

Альтернативный подход

Если возвращаться к команде Drift, то Мэтт Билотти говорит, что отказ от ICE стал возможным благодаря поиску альтернатив. В этом ему помог Дариус Контрактор, который в течение четырех лет развивал Dropbox, руководил отделом роста в Facebook Messenger, а теперь работает Head of Growth в Airtable. Он рассказал Мэтту про подход EVELYN.

Шаблон EVELYN bit.ly/evelyn-airtableШаблон EVELYN bit.ly/evelyn-airtable

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

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

UA число привлеченных пользователей

Marketing costs затраты на маркетинг

C1 конверсия в первую покупку

Buyers количество покупателей

AvP средний чек

ARPC средний доход на клиента (без учета маркетинговых затрат)

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

ARPPU доход с платящего пользователя за вычетом издержек

CAC стоимость привлечения клиента.

CPA стоимость одного привлеченного пользователя в начало воронки и др.

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

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

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

метрика, на которую вы хотите повлиять (в денежном выражении) (a);

во сколько раз эксперимент может увеличить эту метрику (b);

вероятность, что гипотеза сработает, в процентном выражении (c);

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

Вот так выглядит формула:

Value per Day = (a * b * c) / d.

Из презентации Мэтта Билотти на Epic Growth SEASONSИз презентации Мэтта Билотти на Epic Growth SEASONS

Например, метрика влияния ARPU, или средний доход с пользователя, составляет $1. Вы должны определить, во сколько раз эксперимент увеличит вашу метрику. Например, вы предполагаете, что ARPU станет не $1, а $20. Значит, opportunity size будет равен двадцати.

Предположим, вы уверены в успехе на 70%. Значит умножайте на 0,7. Если на реализацию идеи вам понадобится два дня, то полученное произведение цифр нужно разделить на два. Итого получаем: Value per Day = ($1*20*0,7)/2 = $7.

Таким образом, Value per Day метрика отражает, сколько дохода фича может сгенерировать за N потраченных на ее реализацию рабочих дней. Так как в нашем примере Value per Day составил семь долларов, а эксперимент занял два дня, ежемесячно фича будет генерировать доход в четырнадцать долларов ($7*2) до тех пор, пока метрика влияния не изменятся (в ходе новых экспериментов, например).

Источник: unsplash.comИсточник: unsplash.com

После того, как вы получите значения Value per Day для всех гипотез, вам будет легче определиться с тем, за реализацию какой из них взяться в первую очередь. Так вы будете меньше времени тратить на обсуждение мнений и легче доносить ценность своих идей до коллег и руководителей. Если сделать документ с гипотезами открытым, любой человек в компании сможет внести свои идеи или посмотреть список задач в порядке приоритета. Так, у всех членов команды будет понимание того, какие гипотезы находятся в процессе тестирования и какой результат получен по уже проведенным экспериментам. Работа станет более предсказуемой.

Полезные источники по теме

Выступление Мэтта на Epic Growth SEASONS

Фреймворки по приоритизации задачЕще один список фреймворков для управления продуктами

Первоисточник RICE фреймворка в блоге Intercom

DHM подход к приоритизации гипотез от Netflix

Блог Даниила Ханина о юнит-экономике

Подробнее..

Обзор 10 бесплатных систем управления. Что даром, а за что придется платить

20.01.2021 10:13:24 | Автор: admin

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

1) Честная бесплатная версия. Система искренне хочет, чтобы вы свободно пользовались ею без ограничений по времени. И делились с друзьями.

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

Мы в YouGile приняли опасное для себя решение и в октябре запустили честную бесплатную версию. Сняли все ограничения, оставили только одно до 10 пользователей (оплата начиная с 11-го). Результат пока такой: сильно потеряли в количестве платящих клиентов, зато график активности в системе вырос в 2 раза за 3,5 месяца.

Конечно, предварительно мы изучили рынок и посмотрели, а какие free-версии предлагают наши конкуренты: Asana, Bitrix24, Trello и другие. Мы постоянно тестируем разные системы управления и делаем выводы: кто предлагает честную бесплатную версию, а кто нет.

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

Начнем с продуктов, у которых бесплатные версии наиболее полноценные, а также расскажем про свою.

10 бесплатных систем управления

1. YouGile

До 10 человек полностью бесплатная, то есть честная облачная версия. Функционал весь на месте, тот же, что и за деньги, в рукаве ничего не прячем. По сути у нас нет бесплатного и платного тарифа как таковых маленьким командам доступно абсолютно все, всегда и бесплатно. Оплата вводится только за 11-го человека.

Подробнее о тарифах YouGile

Что получится сделать в бесплатной версии:

Организовать сотрудников в системе: указать должности, руководителей, отделы.

Наладить работу с подрядчиками и фрилансерами: настроить права доступа в системе для своих и для чужих.

Создать проекты, доски, задачи, подзадачи.

Сортировать свои и чужие задачи в личном планировщике.

Наладить коммуникации между разными отделами. Например, передавать заказы из отдела продаж на производство.

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

Смотреть, как выполняется работа доступны все виды отчетов и сводок.

Сделать для себя уютное и удобное рабочее пространство: личные доски, свой фон, приватные и избранные задачи, чек-листы, таймеры, дедлайны.

За что точно придется платить:

За пользование системой в больших командах. До 10 человек все бесплатно, за 11-го надо будет платить по 299 рублей в месяц.

За коробочную версию.

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


2. Trello

Крутая бесплатная версия честная. Никаких ограничений по времени и количеству пользователей. Ограничения только по числу досок до 10 штук. И кое-где функционал урезан: не настроить права доступа, не отсортировать карточки, не экспортировать данные, не использовать больше 1 расширения для 1 доски. Раньше было лучше до продажи Trello компании Atlassian. Однако все равно считаем эту версию вполне полноценной для работы в небольших командах.

Подробнее о тарифах Trello

Что получится сделать в бесплатной версии:

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

Можно загружать файлы, главное, чтобы не больше 10 МБ.

Хочется больше общения по задачам есть интеграция со Slack.

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

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

За что точно придется платить:

Больше досок. Если хотите сделать более 10 открытых досок переходите на платный тариф.

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

Тяжелые файлы. Платите, чтобы загружать в задачи 250 МБ.

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

Приоритетная техподдержка. Ответ прилетает на почту в течение 1 дня.

Группировка и объединение досок в коллекции, чтобы не путаться в них.

Сортировка карточек. Навести порядок, упорядочить карточки по последним действиям или числу участников только в платной версии.

Шаблоны досок.

Экспорт данных.

Интеграции без ограничений: более 100 интеграций с Jira, Slack, Google Диск, InVision

Кастомные фоны для досок и пользовательские стикеры. Не самое важное в этом списке, конечно, но упомянем тоже.

Итак, в бесплатной версии Trello можно продуктивно работать, особенно в небольших командах или отделах из 10-15 человек. Надо только все продумать: не создавать лишних досок, выбирать самые важные. Не грузить тяжелые файлы, хранить их где-то отдельно и в карточках просто давать на них ссылки. Интегрировать Slack. Этого вполне хватит. Но, конечно, без расширений, экспорта данных и гибкой настройки прав доступа временами будет нелегко.


3. Bitrix24

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

Подробнее о тарифах Bitrix24

Что получится сделать в бесплатной версии:

Объединить сотрудников даже самой большой команды в общем рабочем пространстве.

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

Создавать группы, проекты, доски, ставить задачи и подзадачи, назначить исполнителей.

Смотреть отчеты.

Хранить 5 ГБ файлов в облаке.

Настроить мобильную CRM.

Интегрировать Bitrix24 с Google Drive, Dropbox, Яндекс Диск, One Drive.

Редактировать документы в режиме онлайн в GoogleDocs и MS Office Online.

За что точно придется платить:

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

Создание воронки продаж. В бесплатной версии можно построить только одну общую воронку.

Сквозная аналитика.

Полноценная IP-телефония. Если планируете контролировать количество и качество звонков переходите на платный тариф. Бесплатно можно записать только 100 звонков, и места дается только 5 ГБ.

Интеграция CRM с 1C. Актуально для многих команд.

Интеграция с почтой, создание email-рассылок.

Настройка прав доступа (на всех уровнях: доступ к задачам, доступ к файлам и папкам, доступ к CRM, к телефонии).

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

Бесплатная версия Bitrix24 вполне подходит для работы, если у вашей команды нет особых запросов. Если вам нужна только работа с задачами спокойно оставайтесь на free-версии. Если же вы хотите построить в системе управления полноценные бизнес-процессы, создать воронки продаж, настроить сквозную аналитику, интегрироваться с 1С и почтой выбирайте платный тариф. Платных тарифов целых 5, они заточены под разные цели. Однако, на наш взгляд, Bitrix24 настолько напичкан всевозможными функциями, что встает вопрос: всегда ли они действительно нужны и легко ли их применять на практике?


4. Pyrus

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

Подробнее о тарифах Pyrus

Что получится сделать в бесплатной версии:

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

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

Обмениваться файлами по задачам, для их хранения дается 1 ГБ свободного места.

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

Есть много фишек в карточках задач: поставить на контроль, отложить на потом, настроить напоминание, повторить задачу.

Выстроить четкую структуру компании и настроить права доступа для разных отделов.

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

Настроить интеграцию с Google Drive, Dropbox, Box, OneDrive, а также с любой CRM.

Автоматизировать документооборот. Согласовывать договоры и платежи, оформлять заявки, работать с запросами от клиентов.

За что точно придется платить:

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

Место на диске. В платной версии его дается в 100 раз больше 100 ГБ вместо 1 ГБ.

Резервное копирование.

Приоритетная техподдержка.

Бесплатная версия системы управления Pyrus подойдет многим командам. Кроме тех, кто имеет дело с большим количеством документов и хочет автоматизировать работу с ними. В общем-то на этот сегмент платящей аудитории и ориентируется система. Еще одно самое неприятное ограничение малый размер места на диске, всего 1 ГБ.


5. Jira

Система Jira, которая чаще всего используется как баг-трекер для отдела разработки самая оплачиваемая система в России. Корпорации закупают ее примерно на 5 миллиардов рублей ежегодно. Однако у нее есть и бесплатная версия до 10 пользователей. В целом мы относим ее к честным, но все же есть серьезные ограничения: дается всего 2 ГБ места, нет расширенных прав доступа.

Подробнее о тарифах Jira

Что получится сделать в бесплатной версии:

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

Пользоваться бизнес-шаблонами проектов (для отделов маркетинга, персонала, юридического и финансового, также есть универсальные шаблоны).

Собрать все рабочие файлы в одном месте: статусы, комментарии и вложения (дается 2 ГБ).

Расставлять приоритеты и дедлайны, контролировать ход работы над проектами.

Обсуждать задачи всей командой.

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

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

За что точно придется платить:

Больше пользователей. Платные тарифы поддерживают до 10000 пользователей.

Больше места в хранилище 250 ГБ и больше.

Расширенные права доступа. Ограничить действия пользователей на уровне проектов и задач можно только в платной версии.

Анонимный доступ. Просмотр и создание задач без входа в систему. Удобно при работе с фрилансерами и подрядчиками.

Журнал событий.

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


6. ClickUp

С первого взгляда кажется, что система предлагает честную бесплатную версию сколько угодно пользователей, сколько угодно задач, навсегда. Но если присмотреться внимательнее увидишь множество ограничений: отчеты, настройка прав доступа, интеграции. Ключевое ограничение: лимит в 100 действий по ряду функций. Так что мы все-таки относим ее к нечестным free-версиям.

Подробнее о тарифах ClickUp

Что получится сделать в бесплатной версии:

Приглашать любое число пользователей в проекты.

Создавать сколько угодно досок, задач и списков и организовывать работу по ним.

Использовать заметки, цифровые блокноты, напоминания и календари.

Анализировать производительность спринтов.

Отслеживать, сколько времени было затрачено на ту или иную задачу.

Смотреть по календарю, когда работа началась и закончилась.

Сортировать задачи по тегам, присваивать им любые статусы.

Получить помощь от техподдержки, круглосуточно.

За что точно придется платить:

Место в хранилище. На бесплатном тарифе дается всего 100 МБ.

Настройка прав доступа.

Гостевой доступ к проектам.

Использование готовых форм.

Отчеты.

Интеграции с Google Drive, Dropbox, OneDriveи другими хранилищами.

Приоритетная техподдержка.

За превышение лимита в 100 действий по ряду функций, ценных для любой системы управления проектами: настройка полей в карточках, использование dashboard, timeline, mind-map и диаграмм Гантта и так далее.

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


7. Wrike

Возможности бесплатной версии сильно ограничены, и прежде всего количеством пользователей до 5 человек. Еще несколько ключевых ограничений: нельзя настроить права доступа, нельзя оценить загрузку и успеваемость сотрудников. По нашему субъективному мнению это нечестная бесплатная версия, то есть пробная.

Подробнее о тарифах Wrike

Что получится сделать в бесплатной версии:

Все стандартно: сделать проекты и доски, повесить задачи, назначить исполнителей.

Задачи можно ставить как на доски, так и в личный планировщик. Можно их сортировать по дате, приоритету, статусу, важности.

Удобно хранить файлы и документы. Документы даже можно редактировать в режиме онлайн.

Общаться с коллегами в Ленте событий.

Интегрировать систему с Google Диск, Dropbox, Box, MSFT Office 365 и OneDrive.

Использовать в своих целях 2 ГБ места.

За что точно придется платить:

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

Любимая многими диаграмма Гантта тоже доступна только на платном тарифе.

Контроль загрузки сотрудников: кто что выполнил, в какие сроки. Есть индекс эффективности и учет рабочего времени.

Права доступа. Сгруппировать сотрудников по командам (отдел маркетинга, бухгалтерия и т.д.), каждой команде назначить права это стоит денег. Как и приглашение гостевых пользователей клиентов, подрядчиков, фрилансеров.

Даже такая мелочь, как календарь только в платной версии.

Основные ограничения бесплатной версии: нет отчетов, нет настройки прав доступа, нет визуализации процессов и контроля загрузки сотрудников. Подходит только для маленьких отделов, где 5 человек. А для личного пользования лучше использовать более простые и интуитивно понятные бесплатные системы управления, такие как Trello. Однако эта free-версия позволяет познакомиться с Wrike и принять решение, подходит вам эта система или нет.


8. Asana

Есть бесплатная версия до 15 пользователей, но ее функционал сильно урезан: нет отчетов, нет возможности контролировать выполнение задач, нельзя следить за обновлениями. Шаг влево, шаг вправо и ты проваливаешься в Активируйте Asana Premium!. Относим ее к нечестным.

Подробнее о тарифах Asana

Что получится сделать в бесплатной версии:

Создать сколько угодно проектов с высоким уровнем декомпозиции на основе шаблонов.

Организовать работу над проектами: создать доски, поставить задачи, назначить исполнителей.

Классифицировать задачи при помощи тегов.

Начать общение в карточках задач и общей новостной ленте.

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

За что точно придется платить:

Отчеты. Вы не сможете посмотреть отчет даже про проектам или исполнителям.

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

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

Визуализация процессов и создание связей между задачами. Timeline недоступен.

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

Работа с формами.

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


9. Worksection

Бесплатная версия очень условная, нечестная: до 2 активных проектов, до 5 пользователей, до 100 МБ на диске. Складывается ощущение, что ее добавили просто как формальность, для галочки. Однако она помогает познакомиться с системой управления тем, кто планирует работать на платном тарифе.

Подробнее о тарифах Worksection

Что получится сделать в бесплатной версии:

Создать всего 2 рабочих проекта. Пригласить до 5 пользователей.

Поизучать систему изнутри: попробовать создать задачу, пообсуждать ее, прикрепить файл.

Возможно, free-версию можно использовать для личных нужд, хотя для этого есть более удобные бесплатные системы управления проектами, тот же Trello.

За что точно придется платить:

Добавление более 2 проектов, задачи и подзадачи, возможность обозначать сроки выполнения, приоритеты, исполнителей, метки, статусы

Ежедневный дайджест, приходящий на email.

Групповые чаты и обмен файлами более 100 МБ.

Диаграмма Гантта.

Функция учета времени, тайм-трекер. Которая помогает посчитать затраты по времени и бюджетам.

Отчеты.

Настройка прав доступа, ограничение прав для клиентов и партнеров.

Бесплатную версию этой системы имеет смысл рассматривать только в том случае, в дальнейшем вы планируете перейти на платный тариф.


10. ToDoist

Бесплатная версия этой системы управления категорически нечестная: до 5 пользователей и до 80 проектов (хотя по сравнению с 2 проектами в Worksection это уже ого-го). Но радоваться рано. Все остальные возможности урезаны практически до нуля. Нельзя добавить более 150 задач, нельзя писать комментарии, нельзя загружать файлы...

Подробнее о тарифах ToDoist

Что получится сделать в бесплатной версии:

Разместить 150 задач.

Подсмотреть, как устроена система изнутри, познакомиться с ней.

За что точно придется платить:

Большее число пользователей и проектов.

Более 150 активных задач.

Напоминания.

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

Загрузка файлов.

Метки для карточек и их классификации.

Фильтры для поиска задач.

Визуализация продуктивности: цели на день и неделю, личный прогресс каждого пользователя.

Разные права для админа и для участника.

Формирование задач из писем в ящике Gmail.

Шаблоны проектов.

Лента событий.

Просмотр видео и прослушивание аудио в самой системе.

По факту бесплатной версии у этого сервиса нет. Да, вы можете создать 80 проектов и сделать целых 150 задач, но какой в этом смысл, если нельзя даже оставить комментарий? Не говоря уже об обмене файлами, напоминаниях, метках и прочих must-have атрибутах любой системы управления. Free-версия здесь только для знакомства.


Сравнение 10 бесплатных систем управления

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

Подробнее..

Выделенная команда прорыв в практике ИТ-аутсорсинга

20.01.2021 18:14:16 | Автор: admin

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

Есть множество моделей взаимодействия, среди них можно выделить: фиксированная стоимость, время и материалы, фиксированное время и бюджет Но среди всех модель Выделенной команды значительно отличается.

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

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

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

Причины, по которым стоит выбрать модель Выделенной команды:

1. Экономическая эффективность
Заказчики значительно экономят на инфраструктуре, поскольку, наняв команду, они получают почасовую оплату за удаленную работу над проектом. Отпадают такие заботы как аренда офиса, приобретение оборудования, оплата счетов за электроэнергию и т.д. Тем более гораздо дешевле нанять уже слаженную команду, нежели самостоятельно искать разработчиков с необходимыми навыками.

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

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

4. Высокая эффективность работы
Команда исполнителей глубоко понимает требования проекта, ориентирована на качество и работает на долгосрочной основе.

5. Прямое общение и мониторинг команды
Согласно данной модели клиент может напрямую управлять каждым специалистом, предоставленным ИТ-компанией.

6. Процесс разработки ПО контролируемый и управляемый
Заказчик участвует в процессе найма ИТ-специалистов, а также управляет процессом разработки на всех этапах, получая регулярные отчеты о выполненных задачах. При желании они могут поручить все работу по проекту аутсорсинговой компании, которая предоставила выделенную команду.

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

8. Масштабируемость команды
С самого начала заказчик самостоятельно решает, сколько человек нужно нанять для разработки ПО. При необходимости клиенты могут добавлять участников, а также уменьшать или увеличивать команду.

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

10. Самая надежная модель из всех
Это достигается за счет гибкости модели, прозрачности и 100% окупаемости наемной команды. Она позволяет избежать многих рисков, в том числе переплаты в процессе создания продукта.

Если вы сомневаетесь, стоит ли нанимать выделенную команду, то помните, вы инвестируете в будущее.

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

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

Подробнее..

Фотограмметрия 100 самых необычных памятников России силами сообщества

21.01.2021 10:23:56 | Автор: admin

Вот что бывает, если вы споткнётесь во время съёмки

Мы в Туту почти полгода проводили конкурс на самый необычный памятник в России. У нас в стране есть и памятник клавиатуре в Екатеринбурге, и всегда метущий к вам спиной дворник, и лабораторная мышь, которая вяжет ДНК в обратную сторону, и двухметровый комар, и вообще что угодно.

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

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

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

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


Процесс съёмки


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

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

Если памятник высокий всё снизу, если ниже человеческого роста или есть дрон можно и покружить сверху.

Снимать можно на что угодно начиная от GPS-дрона (дорогого в аренде и сложного в обращении) и заканчивая телефоном, который есть у всех. На практике после ряда опытов оказалось, что снимать лучше всего на простую, но всё же зеркальную камеру с распространённым (лучше всего китовым) объективом. На дорогую беззеркалку тоже можно, но где ж её на Руси взять-то. Почему важен распространённый объектив и зеркалка потому что шагом дальше нам понадобятся RAW-файлы, которые мы загоним в Лайтрум, где сверху будет наложен корректирующий профиль для объектива, исправляющий геометрию. Если такой профиль не найдётся или будет каким-то творчески-редким, то мы потеряем в точности и модель может неожиданно превратиться в тыкву.

Вот пример превращения в тыкву:



Узнаёте памятник Свидание, где мужик с цветами летит навстречу любви? Нет? А должны. Правда, здесь девушка упала со стремянки во время съёмки.

Вот с такого ракурса, наверное, лучше понятно:



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



А ещё нам важно будет вытаскивать детали в тенях, убирать хроматические аберрации, добавлять резкость и обесцвечивать зелень. Часть памятников, которые снимали ближе к концу конкурса, уже была под сибирским снегом. Снег решался не в Лайтруме, а закрашивался поверх текстуры в Substance Painter, но про это дальше.

Методология съёмки


Итак, чтобы собрать памятник, нужно сделать на типовой объект три круга:
1. Со средней точки.
2. С нижней точки.
3. С верхней точки.

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

Настоящие профессионалы используют опорную RTK-станцию, но мы же работаем силами сообщества, помните?

Снимаем на широкоугольник. Лучше всего 18 мм или 24 мм на 1,6 кропе. Диафрагма закрыта до 7,1 или 9. Есть проблемы с объективами 50 mm fix: например, в основном на них снимали мелкие памятники, и почти при любом диафрагменном числе часть памятника выпадала за границу резкости, и софт тупил. Если памятник высотой до метра, можно снимать даже на диафрагменных числах 9-11, но дальше будут ухудшаться края модели.

Вот так собрались панда и медведь, дружба России и Китая навек. Только постамент:



В итоге мы заказывали моделинг этих медведей 3D-скульптору, потому что это не собралось уже после второй съемки. Выглядят они вот так:



Памятники сделаны из разных материалов. Лучше всего бетон (не для памятника, для съёмки). Бетон надёжен, как Борис Бритва. Бетон обладает массой и почти не бликует. Но бывают памятники из металла и с блестящими краями. Блики с точки зрения софта это дырки в модели.

Поэтому мы стараемся поймать пасмурную погоду (это когда небо затянуто тонким слоем облаков и представляет собой огромный рассеиватель для солнца, то есть свет идёт отовсюду, практически лучший портретный свет). При этом погода должна быть стабильной, потому что съёмка занимает какое-то время и изменение света и цвета нам не очень нужно. Пасмурная погода убирает суперблики. Места с серебрянкой всё равно будут выгибаться на моделях внутрь, и это придётся править руками, но за счёт погоды можно отыграть очень много качества на автоматической сборке. Кто-то может спросить: а почему вы не использовали матирующий спрей? Всё по той же причине краудсорсинга: у нас обычные люди, которые могут неправильно его нанести, плюс потом его же надо счистить щёткой. А в этой ситуации полиция может принять фотографа за вандала.

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

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



Всё остальные сложнее. Вот якутский дворник из Безликих (с другой стороны он точно такой же), на него нужно уже около сотни кадров:



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



И наш рекордсмен Горыныч из Липецка, два прохода по 700 кадров, и всё равно сырая модель была вот такая:



Из-за количества фотографий подхватывалось небо с облаками, которое не было статичным, поэтому вышло что вышло:



Финал для сравнения вот:



Горыныча и подобные памятники собирали долго. Дракона 3 дня, сначала закинули, прогнали, получилось много мусора. Во второй прогон почистили, оставив треть от общего количества кадров. В третий подход сделали примерно для 100 кадров маски (то есть вырезали в фотошопе, целый день в 4 руки этого змея, максимально чисто), и вот после масок на третий день у нас получилась более-менее чистая сборка.

Про Горыныча мы узнали, что в качестве референса для лепки дракона использовалась какая-то старая игрушка, но достать её не удалось, да и скульптор отошёл от неё достаточно далеко. Скажем так, по ней он изучал анатомию этого зверя и его пластику.

А ещё у нас оказалось очень много памятников с кучей деталей. Буквально, из кучи деталей:


Монумент Время. Магаданская область, Магадан.

Вот такой вышел в финал:


Скульптура Динозавр. Псковская область, Опочка.

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

Но была пара исключений. Во-первых, в Новосибирске на территории НИИ стоит мышь, которая плётет ДНК. Вот про неё учёные сказали, что они сами сделают фотограмметрию и пришлют. И сделали. И прислали модель.

Софт для фотограмметрии


Сначала попробовали демоверсию 3DZephirus. Реклама говорит, что они там все просто боги, с ним собирается всё отлично и вообще надо быстрее покупать. Хорошо, что есть демка. В общем, берёте любой опенсорсный пакет (в нашем случае Meshroom) и на наших входных фотографиях всё собирается в сотни раз лучше. Прощай, 3DZephirus, спасибо за сэкономленные 3000 долларов. В защиту этого ПО отмечу, что студийную съёмку с выверенными до миллиметра сдвигами он действительно собирает лучше других. Но это не наш случай.

Потом я увидел, как мой знакомый собрал кроссовки для рекламного ролика с помощью
Agisoft Metashape. Про этот пакет есть хороший перевод на Хабре, вот он. Нашли ещё одну софтину за 699 рублей в месяц RealityCapture (отличный софт, собирающий в 2 клика, в большей части сборки использовали её в итоге). И увидели бесплатный Meshroom. Он с открытым кодом, по сути, похоже на автодесковый набор, чтобы модель зачищать. И зачищает идеально. В итоге мы собирали памятник через Agisoft, Meshroom, RealityCapture (самый простой из всех с отличным результатом, перешли под конец на него) и чистили в Meshmixer (тоже свободный от Автодеска).

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

Кто-то не знал, что закрытие диафрагмы это увеличение диафрагменного числа, а не уменьшение. Стали указывать конкретнее, потому что есть путаница даже между F и f.

Для кого-то выдержка меньше (короче) 1/100 оказывалась 1/20, потому что 20 меньше 100. Или вот звонок Я отснялся, но у вас тут написано снимать в RAW, я в JPG, ничего? Он тоже крутой, но только немного в темноте руки памятника, ничего, да?

Довнесли мысли, что если уж ты начал круг, то идти надо до конца, не отвлекаясь на полости памятника. Некоторые объекты из-за этого переснимали 3 раза. Примерно вот так бывает при нарушении пути (Памятник Сантехник Степаныч. Омская область, Омск):



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

Конкретные примеры памятников, где что-то пошло не так


Здесь владелец памятника снимал сам, не собиралась карта РФ под ногами. Самое простое решение ограничивать ось вращения камеры. Этот памятник можно смотреть только по кругу, без залётов вверх и вниз:



Вот тамбовский волк. Его сняли на восходе, было очень много засветов сзади, долго правили. Суть такая, что снимали спину на восходе против солнца и ловили в объектив жёсткие блики зайцы, поэтому собиралось плохо.



Шоколадная фея из Покрова: снимали тоже на рассвете. Памятник бронзовый, люди его трут. Много пересветов в тех местах, где бронза натёрта:



Дерево желаний в Брянске: ангела можно снять только с коптера, его пришлось моделировать вручную по фотографиям.



Изначально пробовали слепить такого же своими руками из пластилина и отсканить по фотограмметрии в студии. В итоге оказалось проще смоделировать:



Мы купили две модели: это памятник Чижик (очень маленький, его моделировали по фото фактически) и голову Ленина в Бурятии. Потому что голова Ленина ну очень большая и очень сферическая, там нужен был коптер. Ещё 16 были замоделены нами: например, памятник клавиатуре легче нарисовать с нуля по фото, чем сделать фотограмметрию. Здесь нам очень помогли студенты-практиканты, которые учились на 3D-дизайнеров.



Были проблемы, когда какой-то конкретный памятник не собирался с ошибкой ПО. Просто берёт и не собирается. С этой же камеры другой собрался, а на нашем падает. Идём на форум Агисофта, спрашиваем. Нам говорят: а, известная история на Radeon, обновите дрова. А у нас они самые новые, и вообще nVidia. А нам: нет, на ней такой ошибки в принципе быть не может. Купите Радеон и обновите дрова.

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



Собака Дружок из Благовещенска он прилеплен к граниту борта рядом с речкой. За ним лесенки. Чтобы нормально снять только дрон, по факту нет нормального круга:



Реактивный поезд в Твери частично замоделен, благо отдельные компоненты уже были почти готовыми взяли поезд, поставили движки:



Модели финалистов


В финал вышли вот эти памятники:



А победил в конкурсе памятник тувинской письменности, который находится в музее-заповеднике Белдир-Кежии:



Вот файлы моделей для закачки (65 Мб). Это STL-файлы, доступные по лицензии CC BY-NC, то есть вы можете использовать модели для обучения, печати фигурок для личного пользования, но не можете получать выгоду из их использования или включать в производные произведения, которые будут использоваться для получения выгоды.

Посмотреть все 3D-модели 100 памятников в плеерах можно вот здесь.

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

Digital-трансформация завода CRM для ERP, роботизация БП и оживление железа, ЛК, чат-боты и dream team (ч. 2)

21.01.2021 14:15:10 | Автор: admin

Часть 1: CRM для ERP

Часть 2: Роботизация бизнес-процессов (в этой публикации)

Часть 3: Волшебные интерфейсы и оживление железа

Часть 4: Личные кабинеты, чат-боты и dream team

Роботизация бизнес-процессов на примере закупок (2 кейса)

Как часто выглядит процесс закупок на предприятии (без погружения в детали):
  1. Поиск поставщиков и запрос коммерческих предложений.

  2. Сравнение полученных предложений и выбор поставщика.

  3. Заключение договора и осуществление поставки.

Сразу возникают элементарные вопросы:

  1. Где найти поставщиков и как запросить коммерческие предложения?

  2. Как сравнить полученные коммерческие предложения и выбрать поставщика?

  3. Как заключить договор и проконтролировать поставку?

Обычно это происходит так:

  1. Найти поставщиков в справочнике ERP или погуглить, запросить предложения в почте или по телефону.

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

  3. Получить форму договора у поставщика или составить свою и ожидать поставку в срок.

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

Обычный рабочий день менеджера по закупкамОбычный рабочий день менеджера по закупкам

Роботизация бизнес-процесса- это когда все или часть задач конкретного бизнес-процесса выполняют не сотрудники, а система. Таким образом, у сотрудников высвобождается время на выполнение других задач или участие сотрудников исключается полностью (в идеале).

Какие подготовительные этапы были выполнены в ERP до роботизации бизнес-процессов
  1. Исправление ошибок в исторических данных справочника номенклатуры(сначала автоматически с помощью разработанных алгоритмов; затем визуальная проверка и исправление пользователями того, что не удалось однозначно сделать в автоматическом режиме):

    - исправление орфографических ошибки с помощью интеграции сЯндекс.Спеллер

    - удаление "мусорных" символов в наименованиях (спец.символы, кавычки, буквы "ё", лишние пробелы)

    - замена латинских букв в русских словах на буквы кириллицы, и наоборот

    - и другие алгоритмы исправления ошибок в наименованиях (всего 8)

    Разработанные алгоритмы исправления ошибок в наименованиях номенклатуры в ERPРазработанные алгоритмы исправления ошибок в наименованиях номенклатуры в ERP
  2. Упорядочивание данных в справочнике номенклатуры:

    - логическое группирование по видам номенклатуры

    - введение аналогов и замен

  3. Обогащение данных в справочниках контрагентов и контактных лиц:

    - разработка и заполнение портрета поставщика (частично автоматическое на основе исторических данных о поставках в ERP)

    - актуализация контактных данных контрагентов (email, телефоны)

    - актуализация данных контактных лиц контрагентов (ФИО, должность, email, мобильные телефоны)

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

Кейс #1: Роботизация процесса проверки поставщиков

На нашем заводе юридическая проверка поставщиков это обязательная процедура перед заключением договора поставки. В зависимости от категории поставщика и суммы закупки, каждый контрагент (ИП или юр. лицо) должен предоставить от 10 до 20 сканов документов.

В одном процессе участвуют 3-4 сотрудника из разных подразделений:
  • Менеджер по закупкам (ставит задачи менеджеру по документообороту, контролирует ход процесса проверки).

  • Менеджер по документообороту (запрашивает документы у контрагентов и выполняет их первичную проверку).

  • Юрист (выполняет юридическую проверку контрагента и документов).

  • Сотрудник службы безопасности (при необходимости).

ВАЖНО!Чтобы не только правильно выполнялась процедура проверки, но вовремя запрашивалась и поступала информация от поставщиков, вовремя выполнялись и передавались задачи между всем участниками процесса проверки, включая поставщиков.

Для роботизации процесса проверки поставщиков в ERP мы связали в одну систему следующие компоненты:

  • ERP-система (рабочее место сотрудников).

  • Сайт компании (интеграция с ERP и сервисом DaData.ru).

  • Почта Gmail (интеграция с ERP и сайтом).

  • Сервис DaData.ru (интеграция с сайтом и ERP).

  • Сервис 1С:Контрагент (интеграция с ERP).

На сайте компании разработана форма для самостоятельного заполнения контрагентом.

Для простоты заполнения к форме сайта подключен сервис DaData.ru - это и заполнение поле из общедоступных справочников и автоматическое заполнение связанных полей.

Пример формы на сайте для заполнения поставщиком

1, 2, 3, 4 - Заполнение по справочникам из сервиса DaData.ru

5 - Список компетенций поставщиков и подрядчиков из ERP

Все формы на сайте адаптивные, можно легко заполнить на смартфоне.

Пример адаптивной формы на сайте для заполнения поставщиком
Адаптивная форма для заполнения на смартфонеАдаптивная форма для заполнения на смартфоне

Заполненная на сайте форма отправляется в ERP, где автоматически преобразуется в данные - создаются элементы справочников (контрагенты, контактные лица), документ проверки поставщика, задачи для сотрудников, письма с уведомлениями поставщиков.

Пример формы документа проверки поставщика в ERP
Пользовательский интерфейс в ERP для проверки поставщикаПользовательский интерфейс в ERP для проверки поставщика
  1. Текущее состояние проверки поставщика.

  2. Статус предквалификации (отдельный бизнес-процесс, здесь не рассматривается).

  3. Автоматическое определение статуса контрагента (действующий или в состоянии ликвидации).

  4. Досье контрагента на дату начала проверки (автоматически сохранено в PDF).

  5. Досье контрагента на дату открытия документа проверки (динамическое формирование отчета).

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

  7. Автоматическая проверка соответствия кодов ОКВЭД контрагента предмету закупки.

  8. Автоматическая проверка срока регистрации контрагента.

  9. Автоматические задачи сотрудникам, история действий по проверке, автоматические письма контрагенту.

Робот автоматически отклоняет проверку контрагентас отрицательным результатом по 10 признакам, и одновременным уведомлением по email поставщика о причине.

Проверка контрагента в ERP автоматически не пройденаПроверка контрагента в ERP автоматически не пройдена

1 - Робот автоматически устанавливает отрицательный статус проверки и завершает бизнес-процесс проверки.

2 - Робот автоматически определяет причина не прохождения проверки, и автоматически отправляет контрагенту письмо с причиной не прохождения проверки.

3 - Менеджер по закупкам всегда может обосновать проведение проверки, отправив ответственному задачу на согласование (бизнес-процесс проверки будет автоматически инициирован при положительном согласовании).

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

Когда у робота нет причин отклонять проверку,в ERP автоматически стартует бизнес-процесси сотрудники начинают получать автоматические задачи.

Пример задачи, которую получает сотрудник на своем рабочем месте в ERP
Автоматическая задача пользователю от робота в ERPАвтоматическая задача пользователю от робота в ERP

1 - Назначен ответственный

2 - Установлен крайний срок выполнения задачи

3 - Ссылка на документ проверки поставщика

Таким образом,робот автоматически ставит задачи разным сотрудникам(или ролям) при переходе бизнес-процесса проверки на разные этапы.

Пример истории задач сотрудникам при проверке поставщика
История автоматических задач по проверке поставщика в ERPИстория автоматических задач по проверке поставщика в ERP

Все задачи для сотрудников имеют сроки выполнения.Настройки всегда можно изменить в ERP (в пользовательском режиме).

Пример настроек робота в ERP для бизнес-процесса проверки поставщиков

1 - Настройки адресации ролей и сроков выполнения задач ответственными.

2 - Настройка служебных ролей для ожидающих процессов.

3 - Настройка срока ожидания повторного предоставления документов поставщиком (после чего проверка завершается автоматически с отрицательным результатом).

Настройки бизнес-процесса для робота проверки поставщиковНастройки бизнес-процесса для робота проверки поставщиков

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

Сотрудник выявил несоответствия при проверкеСотрудник выявил несоответствия при проверке

Контрагент получает автоматическое письмо по emailдля устранения выявленных замечаний:

1 - Замечание по каждому документу.

2 - Уникальная ссылка с ограниченным сроком действия.

Робот автоматически отправляет email поставщику со ссылкой для повторного предоставления документовРобот автоматически отправляет email поставщику со ссылкой для повторного предоставления документов

Форма на сайте, открытая по уникальной ссылке из письма, предлагает загрузитьтолько те документы, которые запрошеныу контрагента повторно.

Пример формы на сайте для повторного запроса документов
Сгенерированная форма на сайте для повторной отправки документов для проверки контрагентаСгенерированная форма на сайте для повторной отправки документов для проверки контрагента

Циклов повторного запроса может быть несколько, пока контрагент не устранит все замечания и не предоставит требуемые от него документы.

Пример истории почтовых писем от робота по одной проверке поставщика
История автоматических писем в ERP в документе проверки контрагентаИстория автоматических писем в ERP в документе проверки контрагента

Все шаблоны автоматических писем настраиваются в ERP (в пользовательском режиме).

Пример настройки почтовой подсистемы для робота проверки поставщиков

1 - Настройки почтовых ящиков для уведомлений.

2 - Настройка почтовых ящиков для загрузки данных с сайта.

3 - Настройка шаблонов автоматических email для различных событий.

Настройки почтовой подсистемы робота проверки поставщиковНастройки почтовой подсистемы робота проверки поставщиков

Плюсы роботизации бизнес-процесса проверки поставщиков:

1. Из процесса проверки исключен один сотрудник - менеджер по закупкам.

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

2. Поставщики самостоятельно предоставляют данные через сайт.

Высвобождается время у менеджера по документообороту для запроса документов по email, и у поставщика для выяснения вопросов и пересылки писем.

3. Робот автоматически проверяет поставщиков по 10 признакам.

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

4. Робот автоматически ставит задачи сотрудникам разных подразделений.

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

5. Робот автоматически пишет письма поставщикам.

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

6. Не нужно увеличивать штат сотрудников при увеличении числа поставщиков.

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

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

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

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

Настройки и функционал робота проверки статуса ликвидации организаций
Настройки робота проверки статуса ликвидации всех контрагентов в ERPНастройки робота проверки статуса ликвидации всех контрагентов в ERP

Ежедневно ночью робот автоматически проверяет всю базу контрагентов в ERP и актуализирует статус ликвидации по каждому ИП и юр. лицу (интеграция с сервисом DaData.ru).

При обнаружения признака ликвидации у контрагента:

1 - Робот автоматически уведомляет ответственных сотрудников.

2 - Робот приостанавливает оплаты в счет контрагента.

3 - Робот маркирует карточку контрагента в ERP.

Виджет проверки статуса ликвидации в карточке поставщика в ERPВиджет проверки статуса ликвидации в карточке поставщика в ERP

Кейс #2: Роботизация процесса запроса КП у поставщиков

Процесс сбора, обработки и согласования коммерческих предложений не менее трудоемкий, чем процесс проверки поставщиков:

  • Поиск поставщиков и подрядчиков.

  • Запрос коммерческих предложений и их сбор.

  • Сравнение предложений и выбор наилучшего поставщика.

  • Подготовка аналитической записки и согласование с руководителем.

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

Для роботизации процесса запроса и обработки коммерческих предложений в ERP, мы связали в одну систему следующие компоненты:

  • ERP-система (рабочее место сотрудников).

  • Сайт компании (интеграция с ERP).

  • Почта Gmail (интеграция с ERP и сайтом).

Рабочее место менеджера по закупкам в ERP с функционалом запроса КП через сайт

Шаг 1:Менеджер выбирает позиции (1) для запроса предложений через сайт (2).

Выбор позиций номенклатуры для запроса КП через сайтВыбор позиций номенклатуры для запроса КП через сайт

Выбор позиций номенклатуры для запроса КП через сайт

Шаг 2:Робот автоматически выбирает (1), и показывает менеджеру подходящих поставщиков (2) и контактных лиц (3) с заполненными email (4), а также компетенции, результаты проверок и последние поставки (5).

Робот выбрал подходящих поставщиков и контактных лиц для запроса КПРобот выбрал подходящих поставщиков и контактных лиц для запроса КП

Шаг 3:Менеджер выполняет визуальную проверку и запрашивает КП через сайт.

Шаг 4:Для каждого контрагента робот автоматически создает письмо со ссылкой для заполнения коммерческого предложения.

Робот создал и отправил письма с запромо КП каждому поставщикуРобот создал и отправил письма с запромо КП каждому поставщикуПисьма, отправленные роботом из ERPПисьма, отправленные роботом из ERP

На сайте разработана динамическая форма для заполнения поставщиком коммерческого предложения:

1. Условия оплаты (налогообложение, цены с НДС или без, ставка НДС,наличие отсрочки и размер аванса).

2. Условия поставки (способ и срок доставки, наличие и срок гарантии).

3. Товары к поставке (цены, особые условия гарантии, сроков поставки или аналоги).

Пример формы на сайте для заполнения КП поставщиком
Форма на сайте для заполнения коммерческого предложения поставщикомФорма на сайте для заполнения коммерческого предложения поставщиком

Таблицу товаров к поставке можно скачать в Excel.

Пример адаптивной формы на сайта для заполнения КП на смартфоне
Форму коммерческого предложения можно заполнить прямо в смартфонеФорму коммерческого предложения можно заполнить прямо в смартфоне

Важно!Чтобы поставщик не тратил время на подготовку формы коммерческого предложения, ее можно:

  • Скачать уже заполненную прямо на сайте.

  • Распечатать, поставить подпись и печать.

  • Отсканировать и загрузить на сайт.

Пример заполненной формы коммерческого предложения от лика поставщика
Печатная форма коммерческого предложения для скачивания с сайтаПечатная форма коммерческого предложения для скачивания с сайта

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

Такие образом, все коммерческие предложения поступают в ERP автоматически.

После окончания срока приема предложений, в ERP автоматически формируется аналитическая записка.

Робот автоматически формирует аналитическую запискуи сравнивает все предложения от поставщиков по одним и тем же критериям (1), и ранжирует претендентов (2) в порядке убывания.

Аналитическая записка, сформированная роботом в ERPАналитическая записка, сформированная роботом в ERP

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

Мы разработали и других роботов, которые работают в режиме 24/7 и облегчают жизнь.

Спасибо, что дочитали до конца!

Задавайте вопросы, постараюсь на все ответить.

Подробнее..

Почему управлять государством должен продуктовый менеджер?

21.01.2021 22:16:06 | Автор: admin

Потому что государство это продукт. Со своими метриками, экономикой, жизненным циклом. У граждан-пользователей есть и лайфтайм, и отток, и средний чек. Да и цели те же: найти свою нишу на мировом рынке, решить боли пользователей, повысить выручку и капитализацию. Только вот чиновники, которые управляют нашими странами, угробили бы любой стартап примерно сразу.

Рыба с головы портится

Что, если проблема человечества не в перенаселении или глобальном потеплении? Не в бедности, неравенстве и даже не в культуре потребления? Вдруг это всё только следствия?

Думаю, единственная настоящая проблема человечества невероятно хреновый менеджмент.

Если бы у руля стояли компетентные люди, то все проблемы решались бы последовательно и без особых драм. Мы бы вытаскивали самые приоритетные задачи из общечеловеческого бэклога. Фокусировали на них внимание ученых и экспертов. И щелкали их как семечки, одну за одной.

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

Феномен стартапов

Интересно, что хреновость менеджмента распределена неравномерно.

Мы наблюдаем тотальную некомпетентность руководства многих государств, но потрясающий профессионализм в успешных IT-стартапах.

Вероятно, причина в том, что государства могут выживать, будучи неэффективными. При обилии природных ресурсов, например. Или если держать население в нищете. А лучше и то, и другое вместе.

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

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

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

Но и совсем без менеджеров не обойтись

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

Думаю, это провальная история. Как кораблю нужен капитан, так и продукту нужен product owner. Потому что большинство пользователей хочет пользоваться продуктом, а не работать над ним. Кроме того:

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

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

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

  • Большинство пользователей попросту недостаточно компетентно, чтобы принимать осознанные управленческие решения.

  • Наконец, люди легко ведутся на популизм и подвержены стадному инстинкту. Достаточно представить, что им предложили проголосовать за 10-кратное снижение налогов или повышение зарплат. Конечно, большинство эти инициативы с радостью поддержало бы. А в скором времени экономика государства загнулась бы.

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

Давайте порассуждаем, какие IT-методологии было бы классно внедрить в управление государством.

Приоритезированный бэклог

Я открываю новостной Telegram-канал и вижу новые законы, один интереснее другого:

  • Депутаты переименовали улицы

  • Депутаты запретили аниме

  • Депутаты запретили критиковать власть

  • Депутаты увеличили штрафы для водителей

  • Депутаты запретили Telegram

То есть вместо системной работы над ключевыми метриками они пытаются лечить отдельные симптомы костылями да заплатками. Цитируя классику: What is going on inside their head?.

Кто-то скажет: Ну, это отдельные скоморохи всякую ерунду предлагают.

Нет.

Во-первых, это не просто предложения, это принятые законы. А значит, за них проголосовало большинство депутатов.

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

  • Что будет считаться успехом и как ты измеришь результат?

  • Как, по-твоему, это будет внедряться и контролироваться?

  • Как это поможет решить ключевые проблемы государства?

Тот трэш, который мы наблюдаем, возможен только в среде насквозь некомпетентной.

Но, постойте, почему это кажется таким знакомым?

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

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

Поиск точки роста

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

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

Культура гипотез

Откуда берутся гипотезы в здоровом стартапе?

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

Но чиновники выше этой суеты они просто полагаются на чуйку!

Интуиция не подведет!Интуиция не подведет!

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

Не нужны никакие догадки. Любой продакт вам скажет, как искать релевантные гипотезы. Хотите развивать малый бизнес? Идите к предпринимателям и проводите глубинные интервью. Хотите прокачать туризм? Анализируйте опыт стран, которые на этом собаку съели. Хотите понять, что не так с дорогами? Изучайте статистику ДТП на карте.

Риск-менеджмент

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

Конечно, это сложнее, чем раскатать сразу и на всех.

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

Выручает то, что большинство этих законов настолько плохо продуманы, что внедрить и проконтролировать их выполнение попросту невозможно.

Конечно, так быть не должно.

Не вижу ни одной причины, почему бы не обкатать закон сначала на маленькой аудитории или не устроить A/B-тест для оценки его влияния.

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

MVP

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

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

Аналитика и дашборды

Как понять какая партия приносит пользу государству, а какая ему вредит?

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

Какие инструменты стартапов могли бы тут помочь?

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

Что-то в таком духеЧто-то в таком духе

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

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

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

Human-centered design

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

Кхм, извините, в последнем вопросе во мне тоже проснулся депутат.

Типичные постсоветские пейзажи. Автор фотографий: Илья ВарламовТипичные постсоветские пейзажи. Автор фотографий: Илья Варламов

Что было бы со стартапом, который использует неудобный, некрасивый, устаревший дизайн? Вероятно, он потерял бы пользователей, которые ушли бы к конкуренту.

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

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

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

Бонус: пьеса Стыдоба. Или как чиновник продуктом управлял

Трагикомедия в 4-х действиях.

Действующие лица: продакт, чиновник, сисадмин, офис-менеджер, народные массы.

Читать

Действие первое

День до голосования на пост Chief Product Officer в крупном стартапе. Пасмурный опен-спейс с запотевшими окнами. Народные массы мнутся в нетерпении. Входит продакт с микрофоном.

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

(Голос из толпы). Ску-у-учно!

Слышится неодобрительный гул толпы.

(Другой голос). Почему печенье заканчивается в четверг, что нам делать в пятницу?

П р о д а к т (сконфуженно). Но Позвольте Ведь вовсе не о том

Н а р о д (в едином порыве). Прочь! Позор! Прочь!

Продакт, понурившись, спешно покидает помещение.

Действие второе

Место действия то же. Входит чиновник в дорогом костюме.

Ч и н о в н и к. Привет, народ! Я вас люблю!

Толпа одобрительно аплодирует.

Ч и н о в н и к (грозя кулаком куда-то в сторону). А этим всем мы покажем! Нечего тут! Ишь!

Слышится радостное улюлюканье из зала.

Ч и н о в н и к. Я так скажу. К черту метрики! На хрен аналитику! Мы должны поднять всем зарплаты! Вдвое!

Толпа восторженно рукоплещет.

Ч и н о в н и к. Вместе мы сделаем наш продукт великим! Снова!

Народ ликует.

О ф и с - м е н е д ж е р (кричит из толпы). Я хочу от тебя детей! Мой голос за тебя!

Действие третье

Серверная. Темно, холодно. Сисадмин пьет чай. Входит чиновник.

Ч и н о в н и к. Хочу победить на выборах. Подшамань мне голоса. Вот бабла тебе принес.

С и с а д м и н. Ок.

Действие четвертое

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

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

Ненадолго прерывается, чтобы прожевать креветку.

Ч и н о в н и к. А еще неприкосновенность для руководства. И никакого контроля чтоб за расходованием средств. И обеспечить мне личного водителя, а то несолидно как-то...

Чешет пузо и переворачивается на другой бок. Шезлонг жалобно скрипит.

Ч и н о в н и к. Да! Про бездельников этих не забыть же. Увеличить штрафы за опоздания. И зарплаты порезать! А то ишь повадились!

Занавес

Короче, Склифосовский!

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

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


P.S. Конечно, я прошелся по верхам просто чтобы проиллюстрировать идею. Но, может быть, у вас есть мысли какие методологии продуктового или проектного менеджмента хорошо зашли бы в госаппарат? Делитесь в комментариях, пожалуйста.

P.P.S. Должен признать: на самом деле весь этот эффективный менеджмент только полумеры. Потому что государством, очевидно, должна управлять нейросеть. Тогда любая система будет работать как следует хоть нейромонархия, хоть нейрокоммунизм.

Подробнее..

Что нового в SOLIDWORKS 2021

22.01.2021 18:12:57 | Автор: admin

Новая версия SOLIDWORKS 2021 опять радует пользователей новыми функциями и улучшениями в привычных командах все для того, чтобы помочь инженерам разрабатывать продукцию не только быстрее, но и эффективнее. На этот раз разработчики поставили перед собой задачу оптимизировать стандартные рабочие процессы, улучшить быстродействие программы и надежность проектных процедур. Рассмотрим подробнее, где произошли изменения.

SOLIDWORKS CAD

Проектирование сборок

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

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

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

В SOLIDWORKS всегда поддерживалось гибкое изменение конфигурации отдельных экземпляров компонентов в массивах. Иногда нужно, чтобы все компоненты ссылались на исходный экземпляр. Это может оказаться утомительной процедурой, поскольку выполняется для каждого компонента отдельно. Одна из новинок в SOLIDWORKS 2021 это опция, синхронизирующая конфигурации всех экземпляров компонентов в массиве. Она помогает избежать непреднамеренного изменения любого из этих компонентов через быстрое меню, блокируя изменения в диалоговом окне свойств компонента. Это также гарантирует корректность распространения изменений, вносимых в конфигурацию корневого компонента массива. Кроме того, массивы цепочек теперь могут строиться по траектории с заданием длины кривой (а не только длины хорды).

Метод Силуэт, впервые анонсированный в инструменте Defeature в SOLIDWORKS 2019, позволяет создать упрощенное представление сборки с целью защиты проектных данных от несанкционированного распространения, снижения визуальной загроможденности модели и улучшения производительности. Новинкой в SOLIDWORKS 2021 является возможность сохранять упрощенное представление в виде конфигурации в той же сборке, для которой оно было создано. Это избавляет от необходимости управлять отдельным файлом, содержащим упрощенную модель. Для использования упрощенного вида в сборках более высокого уровня достаточно щелкнуть правой кнопкой мыши на компоненте и выбрать Defeatured.

Конструирование деталей

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

Повышение производительности

Улучшена производительность при выполнении таких операций, как открытие, сохранение и закрытие сборок, обнаружение циклических ссылок и создание отчетов о них, а также добавление файлов в хранилище SOLILDWORKS PDM. Ускорено выполнение операций выбора, панорамирования и зумирования. При удалении скрытых объектов и формировании кромок силуэта в чертежах задействовано больше ресурсов графического процессора.

Пользовательский интерфейс

Инженеры давно ценят интуитивно понятный и настраиваемый пользовательский интерфейс SOLIDWORKS. Однако разработчики не успокаиваются на достигнутом! В SOLIDWORKS 2021 интерфейс стал еще более наглядным и удобным. Улучшена цветовая палитра, которая теперь может ссылаться на другие приложения, такие как веб-браузер. Поиск команд в диалоговом окне настройки позволяет легко компоновать панели инструментов. Диспетчер команд можно сворачивать, чтобы получить на экране больше места для работы, а благодаря полупрозрачным размерам упрощается выбор объектов.

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

Взаимодействие на платформе 3DEXPERIENCE

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

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

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

SOLIDWORKS Simulation

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

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

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

В SOLIDWORKS Flow Simulation 2021 расширен круг решаемых задач CFD и продолжает совершенствоваться обработка результатов. Для моделирования вращающихся потоков жидкости служит мощная функция Rotating Region. Теперь в Flow Simulation вращающиеся области можно комбинировать со свободно движущимися поверхностями. Это идеально подходит для задач моделирования смешивания и может быть использовано для анализа поведения изделий в эксплуатации.

SOLIDWORKS Plastics

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

SOLIDWORKS Electrical

Производительность трассировки проводов, кабелей и жгутов в 3D значительно улучшена. Теперь в траекториях наряду с отрезками и дугами также поддерживаются сплайны, что значительно повышает качество трассировки в геометрически сложных изделиях. Добавлены средства расчета массовых свойств системы электрических проводов, кабелей и жгутов внутри 3D-модели разрабатываемого изделия. Несколько проводов/кабелей могут быть закреплены зажимом. Сращивание проводов выполняется с помощью соединительного компонента или без него. В таблицах соединителей и библиотеке аксессуаров поддерживается конечная заделка.

В проектах часто бывает, что несколько кабелей, подключенных к одному и тому же разъему, идут к различным частям электрической системы. Трассировка такой группы кабелей в виде единой сборки не обеспечивает конструкторам достаточной гибкости в принятии решений. В SOLIDWORKS Electrical Schematic 2021 к свойствам кабеля добавлено новое поле, позволяющее отделять один кабель от других. Этот же параметр можно контролировать в команде трассировки кабелей SOLIDWORKS.

SOLIDWORKS PDM

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

SOLIDWORKS PDM 2021 позволяет анализировать и документировать ссылки с помощью вида Treehouse на вкладках Содержит и Где используется. Значки рабочих процессов визуально информируют участников проекта о работе коллег. Стандартные PDM-операции выполняются быстрее, чем в предыдущей версии.

Одной из самых полезных функций SOLIDWORKS PDM уже давно является интеграция с Проводником Windows. В 2021 версии расширена поддержка таких интерфейсных элементов Windows 10, как лента.

Вид Details это место, где проявляется вся широта возможностей PDM. При работе на этом виде в столбцах определяются наборы свойств, которые видны пользователям. SOLIDWORKS PDM 2021 предоставляет больше возможностей для настройки столбцов и, что самое главное, позволяет работать с несколькими наборами столбцов.

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

Предлагаем вам также ознакомиться с новшествами SOLIDWORKS 2021, посмотрев серию вебинаров:

Все вебинары на русском языке. Предварительная регистрация обязательна.

Подробнее..

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

24.01.2021 16:23:06 | Автор: admin

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

Почему это стоит прочесть

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

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

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

Наблюдая за знакомыми мне командами стартапов и за своей собственной, я обратил внимание, что через какое-то время становится сложно поддерживать энтузиазм, атмосферу новаторства и спортивной злости участников проекта. Да что там греха таить, даже сами основатели временами впадают в состояние, как его назвал один мой знакомый фаундер, low energy. А он как раз перед пандемией поднял раунд, но вот локдаун пустил все прахом.

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

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

Неудачи

Любой взрослый человек имел с ними дело, и не надо быть Тони Роббинсом, чтобы понимать их неизбежность. Все мы по умолчанию стараемся их избежать, предугадать, минимизировать риск, одним словом, сделать все то, что и должен делать здравомыслящий человек, даже не будучи основателем стартапа. Так зачем мы вообще это обсуждаем?

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

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

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

А вот полезная сторона принятие. Принятие неудач - отличное решение для построения стратегии развития продукта, команды, и для себя самого: теперь вы точно знаете, чего делать не стоит, а вот что стоит делать становится видно куда отчетливее.

Вывод 1: Неудачи, конечно же, огорчают, но здоровый стартап относится к ним как к части рабочего процесса по тестированию гипотез. Будьте готовы, что неудач при запуске стартапа будет в разы больше, чем если бы вы открыли кофейню пусть даже впервые. Выжимайте из неудач максимум опыта и знаний, который возможен, чтобы поскорее найти оптимальное решение и снизить расходы на тестирование гипотез. Используйте чужие неудачи, посещайте FuckUp nights, это сбережёт и ваши нервы, и ваш бюджет.

Много работы

Я часто встречаю фаундеров, которые говорят, что работают по 16 часов 6 дней в неделю или 24/7, или другие вариации на тему полнейшей перегрузки работой. Мой собственный график основателя не поддаётся никакому анализу. Поверьте, дело не в том, что я безалаберный или бессистемный человек, это не так. Кто меня знает, может это подтвердить.

Причина опять же в том, что стартапы работают на неизведанных ещё территориях. Это требует большого напряжения, фокусировки внимания, всплесков творческой энергии, но не менее часто скучных монотонных многократно повторяющихся рутинных операций. Да, это следствие некоторого авантюризма, который ведёт к неудачам, но, как с ними бороться, мы уже знаем. А как бороться с банальной физической нагрузкой и дисбалансом, да что там говорить, порой с полным провалом в личной жизни?

У меня долгое время не было рецепта. Я заплывал жиром, ничего не успевал на работе, не уделял должного внимания семье. Совершенно естественным образом это весьма неблагоприятно сказывалось и на моем проекте. Очевидная порочная взаимосвязь заставила меня серьезно задуматься над проблемой. Да что там задуматься! Настал момент прекратить это падение это равноускоренное движение к полному краху сразу во всех сферах жизни.

Оглядываясь назад, мне кажется очень закономерным, что многие стартаперы занимаются спортом, биохакингом, йогой и много ещё чем, что способно вернуть мозг к здоровой деятельности. Я не говорю, что все фаундеры, как я склонны к полноте. Как ни странно, но дополнительная физическая нагрузка обеспечивает мозг необходимым ресурсом. Этот ресурс по мере занятий увеличивается и позволяет вывести на новый уровень остальные сферы жизни. В том числе и позволит справляться с большим объемом работы. Тут место для банальности, поэтому привожу цитату Циолковского: Я чувствую после прогулок и плавания, что молодею, а главное, что телесными движениями промассировал и освежил свой мозг.

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

Демотивация

Здесь речь пойдет о мотивации, об отсутствии мотивации и демотивации. Последнее следует воспринимать как мотивацию с отрицательным значением. Все это связано с нашей физиологией, вернее с тем, как ее объясняет моноаминовая теория и с влиянием внешних факторов. Под внешними факторами в основном я имею в виду работу в состоянии неопределенности, высоки нагрузки и опять же неудачи. Если с неудачами и нагрузками мы как-то разобрались, то длительная работа в условиях поиска устойчивой бизнес-модели, рентабельного канала спроса, product-market-fit и прочего, что стартапы постоянно ищут, способна выбить из колеи любого. Даже если у вас кресло от Recaro в комфортном офисе возле дома.

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

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

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

Лидерство и рост

Если вы были топом в большой корпорации, то привыкли, что машина бизнес-процессов крутится будто сама по себе. Отвыкайте. Даже если вы инди-разработчик, кодер в именитой студии или даже в компании из FAGMA (Facebook, Amazon, Google, Microsoft, Apple) с огромным опытом, придется выполнять работу, которую вы раньше не делали.

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

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

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

Вывод 4: Запустить стартап это прекрасный способ проверить себя на прочность. Проверять на эту самую прочность вас будут все, кому не лень: конкуренты, команда, семья, партнеры, клиенты, инвесторы. Будьте готовы!

Не все так плохо

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

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

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

Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru