Иногда каждому открываются окна возможностей.
Кто-то их видит, и его жизнь резко меняется. Кто-то видит, но ничего не делает, упускает возможности. И потом долгое время кусает локти, ожидая следующего окна. А оно может и не открыться. Кто-то не видит таких окон вообще. И считает, что его жизнь сера и убога.
Сегодня для кого-то откроются такие окошки.
Не пропустите :)
Окошко первое.
Образовательный стартап.
С идеей, с первыми проверенными гипотезами, прототипом и клиентами. Идея простая и незамысловатая — помочь специалистам цифровых специальностей развиваться быстрее и осмысленнее. Через модели компетенций, их цифровые паспорта, оцифровку экспертов, контента, практической деятельности. А еще помочь компаниям развивать свои команды.
Нужен исполнительный директор.
Задача простая, но амбициозная — помочь в развитии миллиону людей в следующие 5 лет. И миллиарду в следующие десять :)
Окошко второе.
Федеральная Налоговая Служба.
150 миллионов пользователей. Рынки G2С, G2B и даже G2G. Бизнес-модель: подписка, от которой сложно отказаться :)
Нужен заместитель по ИТ начальника межрегиональной инспекции, отвечающей за ИТ-сервисы ФНС. По сути — руководитель продуктов ФНС. С хорошим ИТ-бэкграундом.
Задача проще некуда — сделать ФНС самой крутой ИТ-конторой в стране. Начав с межрегиональной инспекции.
Если любите челенджи, эти окошки — для вас.
Обращаться ко мне.
Да-да, я и в ФНС тоже.
Кто-то их видит, и его жизнь резко меняется. Кто-то видит, но ничего не делает, упускает возможности. И потом долгое время кусает локти, ожидая следующего окна. А оно может и не открыться. Кто-то не видит таких окон вообще. И считает, что его жизнь сера и убога.
Сегодня для кого-то откроются такие окошки.
Не пропустите :)
Окошко первое.
Образовательный стартап.
С идеей, с первыми проверенными гипотезами, прототипом и клиентами. Идея простая и незамысловатая — помочь специалистам цифровых специальностей развиваться быстрее и осмысленнее. Через модели компетенций, их цифровые паспорта, оцифровку экспертов, контента, практической деятельности. А еще помочь компаниям развивать свои команды.
Нужен исполнительный директор.
Задача простая, но амбициозная — помочь в развитии миллиону людей в следующие 5 лет. И миллиарду в следующие десять :)
Окошко второе.
Федеральная Налоговая Служба.
150 миллионов пользователей. Рынки G2С, G2B и даже G2G. Бизнес-модель: подписка, от которой сложно отказаться :)
Нужен заместитель по ИТ начальника межрегиональной инспекции, отвечающей за ИТ-сервисы ФНС. По сути — руководитель продуктов ФНС. С хорошим ИТ-бэкграундом.
Задача проще некуда — сделать ФНС самой крутой ИТ-конторой в стране. Начав с межрегиональной инспекции.
Если любите челенджи, эти окошки — для вас.
Обращаться ко мне.
Да-да, я и в ФНС тоже.
Много бед в компаниях от непрозрачности.
Неважно какого они размера. Неважно, частные они или государственные. Неважно, какая отрасль. Я время от времени общаюсь с программистами, менеджерами разных уровней, с тим-лидами, с директорами, собственниками бизнесов. Нет-нет, да и всплывет в разговоре: «Вот этот чего-то недоговаривает, вот тут непонятно кто ответственный, вот там вроде что-то делают, а результатов нет».
Непрозрачность бывает разная.
Бывает, настолько запутан продукт, столько в нем слоев — мел, мезозой, юрский период — что чуть тронешь, начинает рассыпаться. Как скалы на южном побережье Англии.
Бывает запутаны процессы. Как устроена разработка? Сколько обращений к нам поступает от клиентов? Сколько у нас инцидентов? Почему стоимость контракта именно такая? На что расходуются средства? Так купишь компанию и годик-другой только из финансовой жопы ее вытаскиваешь. Воруют-с.
Еще, конечно, с людьми проблемы бывают. Сидит Марьванна, за годы к ней привыкли. Раз сидит, значит, что-то делает. А копнешь — да, делает. Только работа ее уже никому не нужна. Умерли давно все. Уволились в смысле. Что умеет? Что знает? Неизвестно. Но зато можно надувать щеки и говорить, насколько ты важен для компании. Дилберта очень на эту тему люблю. На тему щек.
Или наоборот. Известно. Важная персона. Все с ним советуются. Все к нему бегут. Но как его заменить, как задублировать — непонятно. Думать надо. Выяснять. Сложно. Долго.
И так из года в год, из организации в организацию.
Непрозрачно. Непонятно.
А раз непонятно, где проблема, то непонятно, как производительность улучшать. Не работает Голдратт. Хотя нет, конечно, работает. Если непрозрачно, в чем проблема, то проблема в самой непрозрачности. С нее начинать надо.
Вот так и получается, что первый шаг к производительности — прозрачность во всем. Почему во всем? Следите за обновлениями.
В ФБ: https://www.facebook.com/WebByte/posts/1833964513334953
Неважно какого они размера. Неважно, частные они или государственные. Неважно, какая отрасль. Я время от времени общаюсь с программистами, менеджерами разных уровней, с тим-лидами, с директорами, собственниками бизнесов. Нет-нет, да и всплывет в разговоре: «Вот этот чего-то недоговаривает, вот тут непонятно кто ответственный, вот там вроде что-то делают, а результатов нет».
Непрозрачность бывает разная.
Бывает, настолько запутан продукт, столько в нем слоев — мел, мезозой, юрский период — что чуть тронешь, начинает рассыпаться. Как скалы на южном побережье Англии.
Бывает запутаны процессы. Как устроена разработка? Сколько обращений к нам поступает от клиентов? Сколько у нас инцидентов? Почему стоимость контракта именно такая? На что расходуются средства? Так купишь компанию и годик-другой только из финансовой жопы ее вытаскиваешь. Воруют-с.
Еще, конечно, с людьми проблемы бывают. Сидит Марьванна, за годы к ней привыкли. Раз сидит, значит, что-то делает. А копнешь — да, делает. Только работа ее уже никому не нужна. Умерли давно все. Уволились в смысле. Что умеет? Что знает? Неизвестно. Но зато можно надувать щеки и говорить, насколько ты важен для компании. Дилберта очень на эту тему люблю. На тему щек.
Или наоборот. Известно. Важная персона. Все с ним советуются. Все к нему бегут. Но как его заменить, как задублировать — непонятно. Думать надо. Выяснять. Сложно. Долго.
И так из года в год, из организации в организацию.
Непрозрачно. Непонятно.
А раз непонятно, где проблема, то непонятно, как производительность улучшать. Не работает Голдратт. Хотя нет, конечно, работает. Если непрозрачно, в чем проблема, то проблема в самой непрозрачности. С нее начинать надо.
Вот так и получается, что первый шаг к производительности — прозрачность во всем. Почему во всем? Следите за обновлениями.
В ФБ: https://www.facebook.com/WebByte/posts/1833964513334953
#РазговорилисьСегодня (да и вообще в последнюю неделю) о том, какие технические навыки нужны руководителю интернет-продукта.
Вот, дескать, нужно ли ему знать, как задание в разработку ставить. Аналитик же есть. Архитектор в крайнем случае. Принесет к ним менеджер себя со своим потоком сознания, а те структурируют.
Или вот, скажем, про технологии зачем знать. Подумаешь... Если хочу интернет-магазин на блокчейне, так делайте и не жужжите.
Или вот про инциденты. Ну зачем мне, менеджеру, знать про то, что там у вас валяется? И как часто. И тем более почему. Я тут видео виральное придумал, а вы мне говорите, что предупреждать надо было, чтобы сервера не упали под нагрузкой! Вы ж технари, сами думайте заранее. Но денег на железо не просите. Хватит вам 8 гигов памяти. У меня в ноуте 8.
Подход, конечно, имеет право на существование.
Имел. Лет 20 назад. Когда между релизами были месяцы и годы.
Как там... «Да извозчики-то на что ж? Это их дело. Это-таки и наука-то не дворянская. Дворянин только скажи: повези меня туда, свезут, куда изволишь».
Сейчас нужно чуть быстрее. Без извозчиков. Меняя на ходу шапочки и роли. Чтобы на коммуникациях потерь не было. Чтоб в разработку миллионы не вбухать.
Вчера с пользователями, с утра с маркетингом, в обед с разработкой, вечером с продажниками, завтра с поддержкой. И снова с пользователями. И бегом-бегом.
Знания, как устроена разработка, тестирование и эксплуатация, не нужны только в одном случае. Если вы в отрасли ненадолго.
Вот, дескать, нужно ли ему знать, как задание в разработку ставить. Аналитик же есть. Архитектор в крайнем случае. Принесет к ним менеджер себя со своим потоком сознания, а те структурируют.
Или вот, скажем, про технологии зачем знать. Подумаешь... Если хочу интернет-магазин на блокчейне, так делайте и не жужжите.
Или вот про инциденты. Ну зачем мне, менеджеру, знать про то, что там у вас валяется? И как часто. И тем более почему. Я тут видео виральное придумал, а вы мне говорите, что предупреждать надо было, чтобы сервера не упали под нагрузкой! Вы ж технари, сами думайте заранее. Но денег на железо не просите. Хватит вам 8 гигов памяти. У меня в ноуте 8.
Подход, конечно, имеет право на существование.
Имел. Лет 20 назад. Когда между релизами были месяцы и годы.
Как там... «Да извозчики-то на что ж? Это их дело. Это-таки и наука-то не дворянская. Дворянин только скажи: повези меня туда, свезут, куда изволишь».
Сейчас нужно чуть быстрее. Без извозчиков. Меняя на ходу шапочки и роли. Чтобы на коммуникациях потерь не было. Чтоб в разработку миллионы не вбухать.
Вчера с пользователями, с утра с маркетингом, в обед с разработкой, вечером с продажниками, завтра с поддержкой. И снова с пользователями. И бегом-бегом.
Знания, как устроена разработка, тестирование и эксплуатация, не нужны только в одном случае. Если вы в отрасли ненадолго.
Почему для производительности важна прозрачность в людях, в практиках и продукте?
Сложные вещи плохо поддаются осмыслению. Чтобы становились понятнее, их нужно декомпозировать, разбивать на простые составляющие.
Один из способов декомпозиции состоит в том, что бы описать, как объекты (продукты) и субъекты (люди) взаимодействуют друг с другом, по каким правилам (процессы).
Если из этой схемы выбросить любую составляющую, всё разваливается. Не сделать из сложного простое.
Вот, скажем, была компания, в которой процесс публикации новости на сайте выглядел так:
Копирайтер (кто делает?) пишет текст новости и несет его (как делает?) верстальщику (кому?). Верстальщик создает вручную (как делает?) новую страницу с этим текстом, сохраняет в системе контроля версий (как делает, каким инструментом?) и размещает на сайте (на чём?).
После того, как процесс декомпозирован, стал прозрачным, становится понятно, что верстальщик приносит очень мало добавленной стоимости, но увеличивает время выполнения процесса.
Поэтому после оптимизации, процесс становится более эффективным:
Копирайтер (кто?) публикует через онлайн-редактор в системе управления контентом (как? каким инструментом?) новость на сайте (на чём?).
Пока у вас магия "ты мне новость принеси, а я размещу", у вас узкое горлышко. Когда у вас все прозрачно, это горлышко обречено.
Ответьте на три простых вопроса: кто, что, как.
Разберите на три простых компонента: продукт, процессы, пользователи.
И сделайте первый шаг к прозрачности.
Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1840022792729125
Сложные вещи плохо поддаются осмыслению. Чтобы становились понятнее, их нужно декомпозировать, разбивать на простые составляющие.
Один из способов декомпозиции состоит в том, что бы описать, как объекты (продукты) и субъекты (люди) взаимодействуют друг с другом, по каким правилам (процессы).
Если из этой схемы выбросить любую составляющую, всё разваливается. Не сделать из сложного простое.
Вот, скажем, была компания, в которой процесс публикации новости на сайте выглядел так:
Копирайтер (кто делает?) пишет текст новости и несет его (как делает?) верстальщику (кому?). Верстальщик создает вручную (как делает?) новую страницу с этим текстом, сохраняет в системе контроля версий (как делает, каким инструментом?) и размещает на сайте (на чём?).
После того, как процесс декомпозирован, стал прозрачным, становится понятно, что верстальщик приносит очень мало добавленной стоимости, но увеличивает время выполнения процесса.
Поэтому после оптимизации, процесс становится более эффективным:
Копирайтер (кто?) публикует через онлайн-редактор в системе управления контентом (как? каким инструментом?) новость на сайте (на чём?).
Пока у вас магия "ты мне новость принеси, а я размещу", у вас узкое горлышко. Когда у вас все прозрачно, это горлышко обречено.
Ответьте на три простых вопроса: кто, что, как.
Разберите на три простых компонента: продукт, процессы, пользователи.
И сделайте первый шаг к прозрачности.
Обсудить в ФБ: https://www.facebook.com/WebByte/posts/1840022792729125
#РазговорилисьСегодня про жизненный цикл компаний. Про то, какие компетенции нужны на каждой стадии. И нужно ли вообще на части стадий учитывать эти самые компетенции.
Те самые компетенции сотрудников, о которых я уже год пишу. Вот все эти знания и навыки о предметной области или продукте, о процессах и инструментах, о работе с людьми.
Пока пришли к выводу, что такой учет нужен на стадиях взросления компании, на стадии зрелости и на стадии заката.
На этапе детства и юности, кажется, учет не особо нужен.
Вот зачем обычно нашу компанию просят измерить уровень сотрудников или определить взаимосвязи? Либо как-то к мотивации хотят прикрутить (что, кстати, не очень хорошо), либо определить узкие места в команде, либо адаптацию и найм ускорить.
Все эти три штуки, по наблюдениям, характерны, когда статистику детской смертности компания не пополнила. Когда у нее уже начались проблемы роста — вместо 6-7 человек в стартапе она уже перешагнула за первую сотню сотрудников, процессы пора ставить на поток, но непрозрачно и непонятно как.
Когда она уже подошла к кризису среднего возраста и нужно ускоряться, но наследие уже такое, что узкие горлышки не дают это так просто сделать.
Когда она уже близка к пенсионному возрасту и пора начать безболезненно заниматься оптимизацией персонала. Так, чтобы массовые увольнения затронули наименее ценных для компании сотрудников.
А вот на этапе юности, на этапе первых пары лет стартапа, измерять компетенции и вести их учет совсем необязательно. Пока все еще помнят, что за SMM отвечает Рита, а разработка бэка — на Артуре. Пока знают, что за модуль рекомендаций отвечает Андрей, а за найм — вся команда. На этом этапе учет компетенций — излишние затраты на администрирование.
А вот когда Артур, Андрей или Рита наберут себе по отделу, вот тогда пора думать о том, как снизить bus factor, как построить программу развития и как не потратить на это всё миллионы.
Всему своё время. Главное — не проморгать момент.
ФБ: https://www.facebook.com/WebByte/posts/1844148762316528
Те самые компетенции сотрудников, о которых я уже год пишу. Вот все эти знания и навыки о предметной области или продукте, о процессах и инструментах, о работе с людьми.
Пока пришли к выводу, что такой учет нужен на стадиях взросления компании, на стадии зрелости и на стадии заката.
На этапе детства и юности, кажется, учет не особо нужен.
Вот зачем обычно нашу компанию просят измерить уровень сотрудников или определить взаимосвязи? Либо как-то к мотивации хотят прикрутить (что, кстати, не очень хорошо), либо определить узкие места в команде, либо адаптацию и найм ускорить.
Все эти три штуки, по наблюдениям, характерны, когда статистику детской смертности компания не пополнила. Когда у нее уже начались проблемы роста — вместо 6-7 человек в стартапе она уже перешагнула за первую сотню сотрудников, процессы пора ставить на поток, но непрозрачно и непонятно как.
Когда она уже подошла к кризису среднего возраста и нужно ускоряться, но наследие уже такое, что узкие горлышки не дают это так просто сделать.
Когда она уже близка к пенсионному возрасту и пора начать безболезненно заниматься оптимизацией персонала. Так, чтобы массовые увольнения затронули наименее ценных для компании сотрудников.
А вот на этапе юности, на этапе первых пары лет стартапа, измерять компетенции и вести их учет совсем необязательно. Пока все еще помнят, что за SMM отвечает Рита, а разработка бэка — на Артуре. Пока знают, что за модуль рекомендаций отвечает Андрей, а за найм — вся команда. На этом этапе учет компетенций — излишние затраты на администрирование.
А вот когда Артур, Андрей или Рита наберут себе по отделу, вот тогда пора думать о том, как снизить bus factor, как построить программу развития и как не потратить на это всё миллионы.
Всему своё время. Главное — не проморгать момент.
ФБ: https://www.facebook.com/WebByte/posts/1844148762316528
#РазговорилисьСегодня про построение IT-бренда.
Вопрос так и задали: «А как строить крутой IT-бренд? С каких шагов начать?»
Для начала надо понимать, что построение бренда состоит из двух частей: внешний образ и внутренняя культура.
Тяжело строить внешний без сильной подпитки изнутри. Это как продавать несвежую колбасу. Можно ее маслом растительным намазать — снаружи будет блестеть, но внутри будет всё такая же тухлая на вкус.
Для того, чтобы строить сильный внутренний бренд, надо понимать потребности внутреннего клиента — своего сотрудника.
Почему он работает здесь? Что ему мешает работать? Почему уходят сотрудники? Что бы они изменили, чтобы остаться? Каздев, да.
От ответов и начинать плясать. Генерировать гипотезы, быстро проверять, получать обратную связь и на ее основе выстраивать программы обучения, менять офисную среду и тому подобное. Возможно, придется закладывать время на R&D-проекты, а не только на «пашем отсюда и до заката».
И, конечно, постоянно измерять. Придумывать метрики, которые бы говорили, в каком направлении идет изменение бренда. Измерять NPS, считать воронки по изменениям.
Что? Напоминает создание продукта? Удивили.
Оргкультура — вполне себе продукт.
И когда внутри всё хотя б стало на 8-9 из 10, вот тогда можно переходить на внешний бренд. Отправлять евангелистов на конференции, писать на хабре, организовывать митапы для внешних программистов и прочее.
Долго? Да, люди и их отношение быстро не меняются.
Дорого? Есть варианты.
Вот только проблема менеджмента часто в том, что думают о сегодняшнем дне. В фокусе текущих задач. Какая уж там культура...
А время завтрака стратегией всё ближе...
И вот уже стайки программистов потянулись на выход...
Вопрос так и задали: «А как строить крутой IT-бренд? С каких шагов начать?»
Для начала надо понимать, что построение бренда состоит из двух частей: внешний образ и внутренняя культура.
Тяжело строить внешний без сильной подпитки изнутри. Это как продавать несвежую колбасу. Можно ее маслом растительным намазать — снаружи будет блестеть, но внутри будет всё такая же тухлая на вкус.
Для того, чтобы строить сильный внутренний бренд, надо понимать потребности внутреннего клиента — своего сотрудника.
Почему он работает здесь? Что ему мешает работать? Почему уходят сотрудники? Что бы они изменили, чтобы остаться? Каздев, да.
От ответов и начинать плясать. Генерировать гипотезы, быстро проверять, получать обратную связь и на ее основе выстраивать программы обучения, менять офисную среду и тому подобное. Возможно, придется закладывать время на R&D-проекты, а не только на «пашем отсюда и до заката».
И, конечно, постоянно измерять. Придумывать метрики, которые бы говорили, в каком направлении идет изменение бренда. Измерять NPS, считать воронки по изменениям.
Что? Напоминает создание продукта? Удивили.
Оргкультура — вполне себе продукт.
И когда внутри всё хотя б стало на 8-9 из 10, вот тогда можно переходить на внешний бренд. Отправлять евангелистов на конференции, писать на хабре, организовывать митапы для внешних программистов и прочее.
Долго? Да, люди и их отношение быстро не меняются.
Дорого? Есть варианты.
Вот только проблема менеджмента часто в том, что думают о сегодняшнем дне. В фокусе текущих задач. Какая уж там культура...
А время завтрака стратегией всё ближе...
И вот уже стайки программистов потянулись на выход...
Я дурак. В хорошем смысле — учусь на своих ошибках. На чужих тоже умею, но свои как-то лучше запоминаются.
Идти по граблям — это я. Даже, когда грабли заранее видны. Каску, конечно, надену, чтоб не так больно было. Но пойду. Интересно же — сильно бахнет или нет? Поможет каска или в нос прилетит?
Вот, к примеру, знаю же, что бэкапы нужно делать. Но бывает, что жесткий диск гавкнет, а свежих бэкапов нет. Вот месячной давности есть, а вчерашних нет. Зато точно знаю, кто данные быстро восстановит. Но разве свежие бэкапы от этого появится?
Или, к примеру, понятно, что с инвесторами надо на берегу договариваться. Детально. И не только о своих обязательствах, но и об их. Но нет, поверю на слово. Долю продам. А они потом странные вещи предлагают. Ну, конечно, же можно долю выкупить и пару-тройку миллионов на развитие легко достать из своего кармана. Или нового инвестора. Но что ж не попробовать в доверие поиграть?
Или, налоги. Ну вот только что рассказали про проблемы при смене юридического адреса. Но нет же — выплачу-ка я налоги прямо в середине процесса изменения. Ясен пень, и в этом случае знаю, как решить, если что-то потеряется при передаче документов между ИФНС. Но что ж не рискнуть-то?
Конечно, во второй раз не повторю. Или в третий. Или в пятый. И обязательно других предупрежу на очередном выступлении. Авось, они не повторят, авось не дураки.
Вот и получается — все ошибки человечеством давно совершены. И обо многих можно сильно заранее подумать. Только ж положительный опыт неинтересен, мало чему учит. Да и жить так неинтересно, постоянно просчитывая наперед. А вот если шишки набить, то как-то лучше запоминается.
А как у вас?
Идти по граблям — это я. Даже, когда грабли заранее видны. Каску, конечно, надену, чтоб не так больно было. Но пойду. Интересно же — сильно бахнет или нет? Поможет каска или в нос прилетит?
Вот, к примеру, знаю же, что бэкапы нужно делать. Но бывает, что жесткий диск гавкнет, а свежих бэкапов нет. Вот месячной давности есть, а вчерашних нет. Зато точно знаю, кто данные быстро восстановит. Но разве свежие бэкапы от этого появится?
Или, к примеру, понятно, что с инвесторами надо на берегу договариваться. Детально. И не только о своих обязательствах, но и об их. Но нет, поверю на слово. Долю продам. А они потом странные вещи предлагают. Ну, конечно, же можно долю выкупить и пару-тройку миллионов на развитие легко достать из своего кармана. Или нового инвестора. Но что ж не попробовать в доверие поиграть?
Или, налоги. Ну вот только что рассказали про проблемы при смене юридического адреса. Но нет же — выплачу-ка я налоги прямо в середине процесса изменения. Ясен пень, и в этом случае знаю, как решить, если что-то потеряется при передаче документов между ИФНС. Но что ж не рискнуть-то?
Конечно, во второй раз не повторю. Или в третий. Или в пятый. И обязательно других предупрежу на очередном выступлении. Авось, они не повторят, авось не дураки.
Вот и получается — все ошибки человечеством давно совершены. И обо многих можно сильно заранее подумать. Только ж положительный опыт неинтересен, мало чему учит. Да и жить так неинтересно, постоянно просчитывая наперед. А вот если шишки набить, то как-то лучше запоминается.
А как у вас?
Разработка продукта — не единственное, на что программисты направляют свои усилия. Помимо работы над развитием сервисов есть еще три направления.
Первое — это всякая операционка.
Совещания, ритуалы выбранной методологии, мелкие аналитические задачки и тому подобное.
Второе — инфраструктура.
Развитие инструментов разработки и самих разработчиков. Тут деплой автоматизировать, там статейку накидать для коллег.
Третье — поддержка пользователей сервиса.
Баги поправить, разобраться в причинах неработающего сервиса у клиента, вот это вот всё.
Сеньора держать на поддержке обычно дорого. Поэтому на нее отправляют джуниоров. Дескать, пущай расхлебывают всякую мелочь, заодно в проекте разберутся досконально. А чтобы делов не натворили, иногда к ним «дядьку» приставляют дежурить. Код проверить, правки благословить. Во имя отца, сына-наследника и других элементов объектно-ориентированного программирования, ага.
Работа неблагодарная, конечно. Пока старшие товарищи пилят новые фичи, джуниорам авгиевы конюшни разгребать. Неинтересно.
Но если подумать, то общение с пользователями, понимание их проблем и болей — очень ценное времяпровождение. Из такого понимания можно родить новые идеи для развития сервиса. Новые фичи, новые платные услуги и тому подобное. Весь CustDev построен на выявлении потребностей. Только вот сидят на поддержке не те, кто об этом думает. Не знают они об этом — баги правят, стандартные ответы из базы знаний дают.
А что, если вам попробовать объяснить своей поддержке, своим джуниорам суть Customer Development? Чтобы они не просто клиентов успокаивали, а еще и информацию собирали для развития? И идеи генерировали. Заодно мотивацию у джуниоров повысите. Чувство сопричастности — полезное чувство.
Первое — это всякая операционка.
Совещания, ритуалы выбранной методологии, мелкие аналитические задачки и тому подобное.
Второе — инфраструктура.
Развитие инструментов разработки и самих разработчиков. Тут деплой автоматизировать, там статейку накидать для коллег.
Третье — поддержка пользователей сервиса.
Баги поправить, разобраться в причинах неработающего сервиса у клиента, вот это вот всё.
Сеньора держать на поддержке обычно дорого. Поэтому на нее отправляют джуниоров. Дескать, пущай расхлебывают всякую мелочь, заодно в проекте разберутся досконально. А чтобы делов не натворили, иногда к ним «дядьку» приставляют дежурить. Код проверить, правки благословить. Во имя отца, сына-наследника и других элементов объектно-ориентированного программирования, ага.
Работа неблагодарная, конечно. Пока старшие товарищи пилят новые фичи, джуниорам авгиевы конюшни разгребать. Неинтересно.
Но если подумать, то общение с пользователями, понимание их проблем и болей — очень ценное времяпровождение. Из такого понимания можно родить новые идеи для развития сервиса. Новые фичи, новые платные услуги и тому подобное. Весь CustDev построен на выявлении потребностей. Только вот сидят на поддержке не те, кто об этом думает. Не знают они об этом — баги правят, стандартные ответы из базы знаний дают.
А что, если вам попробовать объяснить своей поддержке, своим джуниорам суть Customer Development? Чтобы они не просто клиентов успокаивали, а еще и информацию собирали для развития? И идеи генерировали. Заодно мотивацию у джуниоров повысите. Чувство сопричастности — полезное чувство.
Пришла сегодня в голову мысль.
Вот есть майские указы президента, есть программа «Цифровая экономика». Много чего еще вокруг происходит, где говорят про необходимость модернизации, цифровизации и тому подобное.
И всё бы прекрасно, но перевод госструктур в цифру — очень дорогое удовольствие. Ну потому что там чиновники работают, а не IT-специалисты. А вокруг госстуктур вьются подрядчики, «кровавый энтерпрайз» — вот это вот всё. Этот железку продает, этот софт пишет. И у каждого своя маржа заложена. Ну а как без маржи-то? И переплачивает государство за софт. Ну а что делать? Зарплаты невысокие, программисты в очередь не встают.
А еще рядом есть система, в которой выпускников технических ВУЗов призывают в ряды ВС. Хоть в Бауманке отучился, хоть на ВМК — могут призвать. Если не отмажешься. Или двух не родишь, или еще как-то. И идешь рассказывать про цифровую экономику товарищу прапору. От забора и до обеда.
И вот на фоне этого когнитивного диссонанса мысль следующая: дать выпускникам IT-специальностей выбор. Или в армию на год, или на альтернативную службу. Но не абы какую, а программистами, админами в госструктуры. Пару лет софт писать для Родины. Тысяч за сорок. А чтоб всякое г**но не получалось, к каждой десятке человек приставить вменяемого IT-шника. С опытом в корпорациях, стартапах. Тысяч за 250-300 в месяц. Всё экономия получится относительно текущей ситуации.
И главное, и бывшие студенты опыт по специальности получают без угрозы топтать сапоги, и бывшие сеньоры в IT-менеджеров превращаются. Всё в выигрыше.
И глядишь, начнется-то исправляться ситуация с госуслугами. Прозрачности больше станет. И экономика чуток поцифровеет.
Не, ну а че не попробовать-то? Изменения — наше всё.
ФБ: https://www.facebook.com/WebByte/posts/1863513783713359
Вот есть майские указы президента, есть программа «Цифровая экономика». Много чего еще вокруг происходит, где говорят про необходимость модернизации, цифровизации и тому подобное.
И всё бы прекрасно, но перевод госструктур в цифру — очень дорогое удовольствие. Ну потому что там чиновники работают, а не IT-специалисты. А вокруг госстуктур вьются подрядчики, «кровавый энтерпрайз» — вот это вот всё. Этот железку продает, этот софт пишет. И у каждого своя маржа заложена. Ну а как без маржи-то? И переплачивает государство за софт. Ну а что делать? Зарплаты невысокие, программисты в очередь не встают.
А еще рядом есть система, в которой выпускников технических ВУЗов призывают в ряды ВС. Хоть в Бауманке отучился, хоть на ВМК — могут призвать. Если не отмажешься. Или двух не родишь, или еще как-то. И идешь рассказывать про цифровую экономику товарищу прапору. От забора и до обеда.
И вот на фоне этого когнитивного диссонанса мысль следующая: дать выпускникам IT-специальностей выбор. Или в армию на год, или на альтернативную службу. Но не абы какую, а программистами, админами в госструктуры. Пару лет софт писать для Родины. Тысяч за сорок. А чтоб всякое г**но не получалось, к каждой десятке человек приставить вменяемого IT-шника. С опытом в корпорациях, стартапах. Тысяч за 250-300 в месяц. Всё экономия получится относительно текущей ситуации.
И главное, и бывшие студенты опыт по специальности получают без угрозы топтать сапоги, и бывшие сеньоры в IT-менеджеров превращаются. Всё в выигрыше.
И глядишь, начнется-то исправляться ситуация с госуслугами. Прозрачности больше станет. И экономика чуток поцифровеет.
Не, ну а че не попробовать-то? Изменения — наше всё.
ФБ: https://www.facebook.com/WebByte/posts/1863513783713359
#РазговорилисьСегодня про футбол.
Есть несколько типов людей.
Одни опираются на собственную экспертизу и не слышат окружающих. Другие — с интересом изучают опыт других, осмысливают и стараются применять в своей сфере.
Читаешь прессу и видишь: «Этот тренер когда-то был хорош, но его прагматичный футбол никому не интересен». «У этого были титулы, но до сих пор играет в футбол прошлого десятилетия».
Эти стоны слышу уже четвертый год, наблюдая за развитием Манчестер Юнайтед после ухода сэра Алекса Ф.
В другое ухо слышу: «Программистов нет, маркетолога днем с огнем...». Захудалого миддла в Москве меньше чем на 110-140 еще поискать придется. А уж классного нападающего вам никто меньше чем за 50-80 миллионов фунтов и продавать не станет.
А теперь вернемся к вступлению.
Есть те, кто кричит про отсутствие людей.
А есть те, кто изучает опыт смежных областей. Например, футбола.
То, что хорошие футболисты — это дорого, стало понятно еще в прошлом веке. Сильно раньше того, как в конце нулевых случился Роналду с переходом за десятки миллионов из МЮ в Реал.
Как устроен конвейер по попаданию футболиста в основную команду клуба? Скауты рыщут по всему миру, просматривая десятки и сотни детей с 4-6 лет. Оценивают по характеристикам, наиболее перспективных приводят в клубные академии. Затем годы упорных тренировок по развитию потенциала. Юношеские команды, U-17, U-19, U-21 и так далее. Всё ради того, чтобы однажды клуб получил своего Месси. Или Роналду. Или хотя бы Погбу. Механизм отлажен. Конкуренция — двигатель развития спортсмена.
Наше время. Крупные IT-компании пришли в университеты. Понемногу спускаются в старшие классы школы. Изобретают тот велосипед, который есть в футболе уже десятки лет.
Не изобретайте. Смотрите футбол. Создавайте скаутские сети, академии. Идите в начальную школу. Выстраивайте эту воронку, которая вам даст через годы постоянный поток новых Гиггзов и Зиданов от IT.
Есть несколько типов людей.
Одни опираются на собственную экспертизу и не слышат окружающих. Другие — с интересом изучают опыт других, осмысливают и стараются применять в своей сфере.
Читаешь прессу и видишь: «Этот тренер когда-то был хорош, но его прагматичный футбол никому не интересен». «У этого были титулы, но до сих пор играет в футбол прошлого десятилетия».
Эти стоны слышу уже четвертый год, наблюдая за развитием Манчестер Юнайтед после ухода сэра Алекса Ф.
В другое ухо слышу: «Программистов нет, маркетолога днем с огнем...». Захудалого миддла в Москве меньше чем на 110-140 еще поискать придется. А уж классного нападающего вам никто меньше чем за 50-80 миллионов фунтов и продавать не станет.
А теперь вернемся к вступлению.
Есть те, кто кричит про отсутствие людей.
А есть те, кто изучает опыт смежных областей. Например, футбола.
То, что хорошие футболисты — это дорого, стало понятно еще в прошлом веке. Сильно раньше того, как в конце нулевых случился Роналду с переходом за десятки миллионов из МЮ в Реал.
Как устроен конвейер по попаданию футболиста в основную команду клуба? Скауты рыщут по всему миру, просматривая десятки и сотни детей с 4-6 лет. Оценивают по характеристикам, наиболее перспективных приводят в клубные академии. Затем годы упорных тренировок по развитию потенциала. Юношеские команды, U-17, U-19, U-21 и так далее. Всё ради того, чтобы однажды клуб получил своего Месси. Или Роналду. Или хотя бы Погбу. Механизм отлажен. Конкуренция — двигатель развития спортсмена.
Наше время. Крупные IT-компании пришли в университеты. Понемногу спускаются в старшие классы школы. Изобретают тот велосипед, который есть в футболе уже десятки лет.
Не изобретайте. Смотрите футбол. Создавайте скаутские сети, академии. Идите в начальную школу. Выстраивайте эту воронку, которая вам даст через годы постоянный поток новых Гиггзов и Зиданов от IT.
Получать удовольствие мозг любит больше, чем испытывать стресс. Ничего не делать мозг любит больше, чем напрягаться. Напрягаться — энергозатратно.
Любые изменения энергозатратны. Когда я изучаю что-то новое, мозг просто трещит. Если объем информации большой, может даже голова начать болеть. Поэтому естественная реакция организма — избегать изменений.
Предлагаете новую практику?
Может быть отторжение. Изменяете привычный стиль жизни, пусть даже изменение экономит сотни часов в год? Внедряете новую фишку в свой продукт? Мозг будет сопротивляться. Ваш мозг, мозг клиентов.
Всё, что позволяет мозгу расслабиться, мозг любит.
Перестали собираться на утренние стендапы? Мозг: "Ура!". Перестали писать тесты? Мозг: "Ура-ура!". Перестали бегать по утрам? Ну вы поняли, да?
Не удивительно, что при таком сопротивлении на выработку привычки уходит много времени. Где-то читал, что до 60 дней. До двух месяцев непрерывной работы над закреплением.
Желательно, через положительное подкрепление. Дофамин — отличный способ помочь в закреплении привычки. Если вы хотите начать писать тексты в ФБ, комментарии и лайки подпитают мозг дофамином. Без них два месяца до формирования привычки продержаться будет непросто.
Впрочем, и после двух месяцев, не факт, что станет проще.
У меня это примерно сотый пост за последний год. Но и то, нет-нет привычка и сбойнет, и пропускаю дату очередной заметки.
Так что, если хотите у сотрудников вырабатывать привычки, задумайтесь о положительном стимулировании. Кнут работает плохо. После кнута кортизол вырабатывается. Не дофамин.
Любые изменения энергозатратны. Когда я изучаю что-то новое, мозг просто трещит. Если объем информации большой, может даже голова начать болеть. Поэтому естественная реакция организма — избегать изменений.
Предлагаете новую практику?
Может быть отторжение. Изменяете привычный стиль жизни, пусть даже изменение экономит сотни часов в год? Внедряете новую фишку в свой продукт? Мозг будет сопротивляться. Ваш мозг, мозг клиентов.
Всё, что позволяет мозгу расслабиться, мозг любит.
Перестали собираться на утренние стендапы? Мозг: "Ура!". Перестали писать тесты? Мозг: "Ура-ура!". Перестали бегать по утрам? Ну вы поняли, да?
Не удивительно, что при таком сопротивлении на выработку привычки уходит много времени. Где-то читал, что до 60 дней. До двух месяцев непрерывной работы над закреплением.
Желательно, через положительное подкрепление. Дофамин — отличный способ помочь в закреплении привычки. Если вы хотите начать писать тексты в ФБ, комментарии и лайки подпитают мозг дофамином. Без них два месяца до формирования привычки продержаться будет непросто.
Впрочем, и после двух месяцев, не факт, что станет проще.
У меня это примерно сотый пост за последний год. Но и то, нет-нет привычка и сбойнет, и пропускаю дату очередной заметки.
Так что, если хотите у сотрудников вырабатывать привычки, задумайтесь о положительном стимулировании. Кнут работает плохо. После кнута кортизол вырабатывается. Не дофамин.
Вёл на днях занятие про технические основы интернета.
Зашла речь про протоколы и API.
Как объяснить людям, что это такое?
Помогли собаки.
Протокол — по сути набор соглашений, по которому происходит обмен данными. Или еще проще — команды и ответы на них.
Вот, скажем, во многих собаках есть поддержка базового протокола послушания. «Сидеть», «стоять», «лежать», «фу» — эти команды знакомы многим собакам. Может быть разная скорость отклика. Может быть разная реализация, как именно реализуется «лежать». К примеру, одна моя знакомая собака на эту команду ложится на бок. Примерно также и веб-серверы поддерживают HTTP — протокол передачи гипертекста. Очень похоже поддерживают. Но местами есть нюансы.
У многих интернет-сервисов есть свои протоколы работы — API. Сервисом предоставляется какой-то набор команды. Иногда разные сервисы предоставляют очень похожие API — лайкнуть пост, поделиться страничкой и так далее.
У собак API тоже есть. Вот, к примеру, мой Ферги и мой Edwin выставляют наружу расширение базового протокола. Например, в него входит команда «Обнимашки». Но есть у них и отличия. В одном псе реализована команда «На спинку». А второй эту команду не знает, но неплохо поддерживает команду «Леж».
Всего в API моих собак несколько десятков команд.
Есть команды перемещения в пространстве: «Право», «Лево», «Вперед», «Обойди». Есть команды, связанные с приемом пищи. Это вообще наиболее хорошо реализованный блок команд: «Кушать», «Жрать», «Рубец», «Помидор», «Вкусняшка», «Печенка», «Мясо» и даже «Трахея». Все эти команды (и еще 30-40 обозначений еды) прекрасно известны моим псам. А вот команда «Голос» не реализована. Вместо нее старший реагирует на «You scouse bastard!». Профессиональная деформация у него.
В общем, если хотите что-то сложное рассказать простым языком, ищите аналогии. Собаки — хороший тому пример.
Зашла речь про протоколы и API.
Как объяснить людям, что это такое?
Помогли собаки.
Протокол — по сути набор соглашений, по которому происходит обмен данными. Или еще проще — команды и ответы на них.
Вот, скажем, во многих собаках есть поддержка базового протокола послушания. «Сидеть», «стоять», «лежать», «фу» — эти команды знакомы многим собакам. Может быть разная скорость отклика. Может быть разная реализация, как именно реализуется «лежать». К примеру, одна моя знакомая собака на эту команду ложится на бок. Примерно также и веб-серверы поддерживают HTTP — протокол передачи гипертекста. Очень похоже поддерживают. Но местами есть нюансы.
У многих интернет-сервисов есть свои протоколы работы — API. Сервисом предоставляется какой-то набор команды. Иногда разные сервисы предоставляют очень похожие API — лайкнуть пост, поделиться страничкой и так далее.
У собак API тоже есть. Вот, к примеру, мой Ферги и мой Edwin выставляют наружу расширение базового протокола. Например, в него входит команда «Обнимашки». Но есть у них и отличия. В одном псе реализована команда «На спинку». А второй эту команду не знает, но неплохо поддерживает команду «Леж».
Всего в API моих собак несколько десятков команд.
Есть команды перемещения в пространстве: «Право», «Лево», «Вперед», «Обойди». Есть команды, связанные с приемом пищи. Это вообще наиболее хорошо реализованный блок команд: «Кушать», «Жрать», «Рубец», «Помидор», «Вкусняшка», «Печенка», «Мясо» и даже «Трахея». Все эти команды (и еще 30-40 обозначений еды) прекрасно известны моим псам. А вот команда «Голос» не реализована. Вместо нее старший реагирует на «You scouse bastard!». Профессиональная деформация у него.
В общем, если хотите что-то сложное рассказать простым языком, ищите аналогии. Собаки — хороший тому пример.
Ретроспектива — крайне полезный инструмент. Не знаю уж почему участие в таких встречах считают скучным и неинтересным.
Не в курсе, что это такое?
Ретроспектива — встреча, на которой обсуждается работа команды. Нет-нет, не для того, чтобы найти виноватых и раздать люлей. Ретроспектива проводится, чтобы зафиксировать полезные практики, которые применяла команда в работе. И чтобы найти узкие места, мешающие команде двигаться еще быстрее. И понять, как их можно устранить.
Почему новую фичу запустили в срок? Потому что вовремя предупредили админов о настройке БД? Потому что тестировщики участвовали в обсуждении требований? Зафиксируем. Попробуем повторить еще раз.
Почему в нашем ресторане блюдо стало в стоп-лист в пятницу вечером? Потому что было недостаточно заготовок? Потому что закончился какой-то ингредиент? Зафиксируем.
Узких мест обычно несколько. Какие-то из них мешают сильно. От других команда просто испытывает легкое неудобство. Как и при создании продукта, нужно определять приоритеты — что исправлять, а что стоит отложить. Критерии могут быть разные. Количество матерных слов от заказчика. Размер недополученной прибыли. Количество жалоб от постоянных клиентов.
После приоритизации начинается самая интересная часть ретры — придумать, как с минимальными усилиями расширить узкое место. Или хотя бы не допустить в будущем. Проактивный инцидент-менеджмент начинается. Очень творческий зачастую процесс. Особенно, когда доходит до вопроса: «Кто возьмет на себя исправление проблемы?»
И, конечно, как и в инцидент-менеджменте главное — это чтобы встреча не прошла впустую. И принятые на ней решения и взятые обязательства были доведены до результата. Если не будут, ретроспектива останется бесполезным мероприятием. Скучным и неинтересным.
Ретроспектива — та же обратная связь.
А обратная связь — наше всё.
Цените ретроспективы.
Не в курсе, что это такое?
Ретроспектива — встреча, на которой обсуждается работа команды. Нет-нет, не для того, чтобы найти виноватых и раздать люлей. Ретроспектива проводится, чтобы зафиксировать полезные практики, которые применяла команда в работе. И чтобы найти узкие места, мешающие команде двигаться еще быстрее. И понять, как их можно устранить.
Почему новую фичу запустили в срок? Потому что вовремя предупредили админов о настройке БД? Потому что тестировщики участвовали в обсуждении требований? Зафиксируем. Попробуем повторить еще раз.
Почему в нашем ресторане блюдо стало в стоп-лист в пятницу вечером? Потому что было недостаточно заготовок? Потому что закончился какой-то ингредиент? Зафиксируем.
Узких мест обычно несколько. Какие-то из них мешают сильно. От других команда просто испытывает легкое неудобство. Как и при создании продукта, нужно определять приоритеты — что исправлять, а что стоит отложить. Критерии могут быть разные. Количество матерных слов от заказчика. Размер недополученной прибыли. Количество жалоб от постоянных клиентов.
После приоритизации начинается самая интересная часть ретры — придумать, как с минимальными усилиями расширить узкое место. Или хотя бы не допустить в будущем. Проактивный инцидент-менеджмент начинается. Очень творческий зачастую процесс. Особенно, когда доходит до вопроса: «Кто возьмет на себя исправление проблемы?»
И, конечно, как и в инцидент-менеджменте главное — это чтобы встреча не прошла впустую. И принятые на ней решения и взятые обязательства были доведены до результата. Если не будут, ретроспектива останется бесполезным мероприятием. Скучным и неинтересным.
Ретроспектива — та же обратная связь.
А обратная связь — наше всё.
Цените ретроспективы.
Рынок программистов похож на рынок футболистов. Хорошие стоят достаточно дорого. Начинающие с трудом могут попасть в свою первую команду.
Топ-компании понемногу начинают открывать свои «футбольные» академии, выращивая себе программистов из перспективных начинающих.
Но многого рынок программистов от футболистов еще не перенял. Например, нет агентов, которые помогают программисту переподписать контракт на улучшенных условиях. Или ищут ему новый проект поинтереснее.
Представьте себе HR'а, который в блокнотике имеет десятки программистов. Помнит, кто где работает, знает, на каких условиях. Раскручивает их личные бренды, организовывает выступления. И раз в полтора-два года помогает поднять зарплату. Или перейти в новую компанию. И берет свои бонусы за переход. 50. 100. 150К. Представили? Облизнулись? Не забудьте старика, когда реализуете эту идею :)
Вообще, нормальный эйчар внутри компании должен внимательно смотреть за программистами. Начал смотреть на сторону? Забудьте про лояльность к компании. Помогите ему найти новую работу. Возьмите с новой компании денег за переход. И вы без дела не будете сидеть — нового искать придется. И он уйдет с благодарностью. Еще и денег получите на новый трансфер. Ой, простите, на нового сотрудника.
В каждой шутке есть доля шутки. А в каждом программисте дремлет свой Неймар, Модрич или Кейн. Интересно, в скольки HRах дремлет Мино Райола?
Топ-компании понемногу начинают открывать свои «футбольные» академии, выращивая себе программистов из перспективных начинающих.
Но многого рынок программистов от футболистов еще не перенял. Например, нет агентов, которые помогают программисту переподписать контракт на улучшенных условиях. Или ищут ему новый проект поинтереснее.
Представьте себе HR'а, который в блокнотике имеет десятки программистов. Помнит, кто где работает, знает, на каких условиях. Раскручивает их личные бренды, организовывает выступления. И раз в полтора-два года помогает поднять зарплату. Или перейти в новую компанию. И берет свои бонусы за переход. 50. 100. 150К. Представили? Облизнулись? Не забудьте старика, когда реализуете эту идею :)
Вообще, нормальный эйчар внутри компании должен внимательно смотреть за программистами. Начал смотреть на сторону? Забудьте про лояльность к компании. Помогите ему найти новую работу. Возьмите с новой компании денег за переход. И вы без дела не будете сидеть — нового искать придется. И он уйдет с благодарностью. Еще и денег получите на новый трансфер. Ой, простите, на нового сотрудника.
В каждой шутке есть доля шутки. А в каждом программисте дремлет свой Неймар, Модрич или Кейн. Интересно, в скольки HRах дремлет Мино Райола?
Вселенная опять открывает возможности. Менеджерам уже открылись. Теперь настало время для программистов с аналитиками.
Сегодня я буду Морфеусом.
Слушайте меня, будущие Нео и Тринити.
Хотите детям рассказывать, что именно вы сделали наше государство по-настоящему цифровым, а его услуги максимально доступными ста пятидесяти миллионам россиян? Или хотите рассказывать о том, что был шанс, но вы его благополучно профукали?
Если вы про «профукать», дальше можете не читать.
А если готовы поработать над проектом, который станет реальной основой для цифрового будущего, то вам ко мне.
Проект самоубийственный. Много данных. Десятки поставщиков. Конфликты. Высоченные нагрузки. Смарт-контракты. Кровавый энтерпрайз. Всего год до запуска в пром и месяц уже прошел. Челендж будь здоров.
Мне нужны Java-программисты, способные выжать максимум из кода. Мне нужны аналитики, способные разобраться в десятках форматах и хакнуть текущую систему разрозненных государственных данных. Мне нужны смелые люди, которые вместе со мной будут сражаться с машинами.
В Москве, в Питере, в других регионах — почти неважно где вы. Условия — более чем.
Следуй за белым кроликом, Нео.
Впиши себя в историю. Пиши мне.
В ФБ: https://www.facebook.com/WebByte/posts/1900136203384450
Сегодня я буду Морфеусом.
Слушайте меня, будущие Нео и Тринити.
Хотите детям рассказывать, что именно вы сделали наше государство по-настоящему цифровым, а его услуги максимально доступными ста пятидесяти миллионам россиян? Или хотите рассказывать о том, что был шанс, но вы его благополучно профукали?
Если вы про «профукать», дальше можете не читать.
А если готовы поработать над проектом, который станет реальной основой для цифрового будущего, то вам ко мне.
Проект самоубийственный. Много данных. Десятки поставщиков. Конфликты. Высоченные нагрузки. Смарт-контракты. Кровавый энтерпрайз. Всего год до запуска в пром и месяц уже прошел. Челендж будь здоров.
Мне нужны Java-программисты, способные выжать максимум из кода. Мне нужны аналитики, способные разобраться в десятках форматах и хакнуть текущую систему разрозненных государственных данных. Мне нужны смелые люди, которые вместе со мной будут сражаться с машинами.
В Москве, в Питере, в других регионах — почти неважно где вы. Условия — более чем.
Следуй за белым кроликом, Нео.
Впиши себя в историю. Пиши мне.
В ФБ: https://www.facebook.com/WebByte/posts/1900136203384450
#РазговорилисьСегодня про работу госорганов. Да что уж скрывать — очередную жалобу обсуждали.
Дескать, ведомство "А" обидело. Всё бы ничего, но реально дело не в ведомстве "А", а в ведомстве "Б", которое некорректные данные передало в первое ведомство. Или не передало вообще. Или передало когда-то корректно, а потом некорректности добавило. Или еще что-то сделало не то. Но по факту, у ведомства "А" данные грязные, из-за чего услугу гражданам указывает не всегда качественно.
Казалось бы, при чем здесь IT?
А вот при чем. В распределенных базах данных невозможно обеспечить одновременно согласованность, доступность и устойчивость.
Согласованность — отсутствие противоречий в каждый момент времени между частями системы. Доступность — любой запрос завершается корректным откликом (но без гарантий, что везде одинаковым). Устойчивость — способность выдавать корректный отклик, даже если система распалась на несколько узлов.
Кому интересно, почему нельзя — почитайте про CAP-теорему (она же теорема Брюера).
Вот и получается, что даже в нормально построенных системах возможна рассинхронизация данных.
Что уж говорить про IT-системы ведомств, которые часто построены абы как? Где-то данные централизованы, где-то децентрализованы по регионам. Они и между собой-то не всегда корректно работают. А уж когда такие странные образования пытаются взаимодействовать друг с другом, жди фигни. «От нас ушло», ага.
Что с этим делать? Долго и мучительно переделывать архитектуру. Где-то строя новые системы, где-то по частям меняя старые. Специалисты со стажем прекрасно понимают, что ошибки проектирования — очень дорогие на этапе эксплуатации. Особенно через годы внедрения. Особенно, когда несколько раз поменялись программисты (читай "подрядчики").
Сколько это займет? Не знаю.
Ни по времени, ни по количеству седых волос.
Долго, дорого, страшно. Кто ж хочет в такие авантюры ввязываться?
Только смелые духом :)
Хотите поучаствовать в изменении этой ситуации? Хотите победить стоглавую гидру? Идите ко мне. Менеджерами продуктов, программистами, аналитиками, тестировщиками. В одно из самых продвинутых в части IT ведомств. Кто, если не мы?
—-
В ФБ: https://www.facebook.com/WebByte/posts/1904673609597376
Дескать, ведомство "А" обидело. Всё бы ничего, но реально дело не в ведомстве "А", а в ведомстве "Б", которое некорректные данные передало в первое ведомство. Или не передало вообще. Или передало когда-то корректно, а потом некорректности добавило. Или еще что-то сделало не то. Но по факту, у ведомства "А" данные грязные, из-за чего услугу гражданам указывает не всегда качественно.
Казалось бы, при чем здесь IT?
А вот при чем. В распределенных базах данных невозможно обеспечить одновременно согласованность, доступность и устойчивость.
Согласованность — отсутствие противоречий в каждый момент времени между частями системы. Доступность — любой запрос завершается корректным откликом (но без гарантий, что везде одинаковым). Устойчивость — способность выдавать корректный отклик, даже если система распалась на несколько узлов.
Кому интересно, почему нельзя — почитайте про CAP-теорему (она же теорема Брюера).
Вот и получается, что даже в нормально построенных системах возможна рассинхронизация данных.
Что уж говорить про IT-системы ведомств, которые часто построены абы как? Где-то данные централизованы, где-то децентрализованы по регионам. Они и между собой-то не всегда корректно работают. А уж когда такие странные образования пытаются взаимодействовать друг с другом, жди фигни. «От нас ушло», ага.
Что с этим делать? Долго и мучительно переделывать архитектуру. Где-то строя новые системы, где-то по частям меняя старые. Специалисты со стажем прекрасно понимают, что ошибки проектирования — очень дорогие на этапе эксплуатации. Особенно через годы внедрения. Особенно, когда несколько раз поменялись программисты (читай "подрядчики").
Сколько это займет? Не знаю.
Ни по времени, ни по количеству седых волос.
Долго, дорого, страшно. Кто ж хочет в такие авантюры ввязываться?
Только смелые духом :)
Хотите поучаствовать в изменении этой ситуации? Хотите победить стоглавую гидру? Идите ко мне. Менеджерами продуктов, программистами, аналитиками, тестировщиками. В одно из самых продвинутых в части IT ведомств. Кто, если не мы?
—-
В ФБ: https://www.facebook.com/WebByte/posts/1904673609597376
21 век будет веком, когда индивидуальность в потреблении выйдет на первый план.
Индивидуально приготовленная еда.
Потому что наш организм выделяет больше всего дофамина именно в ответ на данное сочетание молекул. И именно оно позволяет максимально эффективно пополнять энергетический баланс организма. И именно оно позволяет меньше изнашиваться клеткам организма. Ну и эстетически красиво тоже оно.
Индивидуально сделанная одежда и обувь.
Потому что именно эти формы удобнее для тела. А фасон и цвета наиболее приятны для собственного взгляда, если мнение других тебе неважно. Или предпочтений компании людей, в которую ты идешь, если важно.
Или индивидуально сгенерированная музыка.
Потому что эти ноты, длительность, ритм, инструменты и тембр голоса вызывают наиболее яркие эмоции. Да-да, снова гормоны и нейрофизиология.
И так далее.
При этом индивидуальность не означает однообразия. Наоборот. Полная свобода. Миллиарды комбинаций.
Но для того, чтобы получить такую свободу, придется пожертвовать частью свободы личной. Датчики, анализ действий, обработка гигантского объема информации. Но мы сделаем этот шаг добровольно. Потому что это ведь не кажется таким ограничением — еще один фитнес-браслет, еще одна серьга в ухе, еще одно кольцо или часы. А то там оно еще куда передает... Да какая разница, да? :)
Индивидуально приготовленная еда.
Потому что наш организм выделяет больше всего дофамина именно в ответ на данное сочетание молекул. И именно оно позволяет максимально эффективно пополнять энергетический баланс организма. И именно оно позволяет меньше изнашиваться клеткам организма. Ну и эстетически красиво тоже оно.
Индивидуально сделанная одежда и обувь.
Потому что именно эти формы удобнее для тела. А фасон и цвета наиболее приятны для собственного взгляда, если мнение других тебе неважно. Или предпочтений компании людей, в которую ты идешь, если важно.
Или индивидуально сгенерированная музыка.
Потому что эти ноты, длительность, ритм, инструменты и тембр голоса вызывают наиболее яркие эмоции. Да-да, снова гормоны и нейрофизиология.
И так далее.
При этом индивидуальность не означает однообразия. Наоборот. Полная свобода. Миллиарды комбинаций.
Но для того, чтобы получить такую свободу, придется пожертвовать частью свободы личной. Датчики, анализ действий, обработка гигантского объема информации. Но мы сделаем этот шаг добровольно. Потому что это ведь не кажется таким ограничением — еще один фитнес-браслет, еще одна серьга в ухе, еще одно кольцо или часы. А то там оно еще куда передает... Да какая разница, да? :)
#РазговорилисьСегодня про итеративную инкрементальную разработку. Она ж IID.
Ту, при которой каждую итерацию выпускается готовый продукт. Да, с небольшим приростом. Да, возможно, далёким от идеального. Но зато с таким, который уже можно показывать пользователям. И получать обратную связь не через месяцы разработки, а чуть раньше.
Говорили мы на эту тему со сторонниками кровавого энтерпрайза. С ТЗ на сотни листов, с глубокой многомесячной проработкой десятками аналитиков итп. Объяснял им, как наш продукт-то можно начать щупать уже через 2-3 недели.
Но в ответ получил две таких вот фразы
1. Этот ваш Скрум подходит для веб-систем, а для серьезных проектов не подходит.
2. Методология молодая, наш проектный подход проверенный и рисков меньше.
Что я могу на это ответить:
1. Итерации и инкрементальная разработка != гибкие методологии. Agile вообще про другое.
2. IID настолько стар, что про него писал ещё Брукс в своей "Серебряной пули нет". И он был далеко не первым. Шухарт вообще в 1967 умер. Да-да, цикл Plan-Do-Check-Act был задолго до написания Agile-манифеста.
3. Что только не делали с помощью IID. Даже самолёты. Ограничений на технологии не накладывает.
4. Величина рисков не зависит от методологии. Хотя использование незнакомых инструментов риски может породить. Зато убрать другие.
5. Scrum не произносится как "Скрум". Конечно, если вы не из Ланкашира, UK.
В общем, только хардкор, только факт-чекинг. Ну а изменений все боятся. Эт нормально.
Ту, при которой каждую итерацию выпускается готовый продукт. Да, с небольшим приростом. Да, возможно, далёким от идеального. Но зато с таким, который уже можно показывать пользователям. И получать обратную связь не через месяцы разработки, а чуть раньше.
Говорили мы на эту тему со сторонниками кровавого энтерпрайза. С ТЗ на сотни листов, с глубокой многомесячной проработкой десятками аналитиков итп. Объяснял им, как наш продукт-то можно начать щупать уже через 2-3 недели.
Но в ответ получил две таких вот фразы
1. Этот ваш Скрум подходит для веб-систем, а для серьезных проектов не подходит.
2. Методология молодая, наш проектный подход проверенный и рисков меньше.
Что я могу на это ответить:
1. Итерации и инкрементальная разработка != гибкие методологии. Agile вообще про другое.
2. IID настолько стар, что про него писал ещё Брукс в своей "Серебряной пули нет". И он был далеко не первым. Шухарт вообще в 1967 умер. Да-да, цикл Plan-Do-Check-Act был задолго до написания Agile-манифеста.
3. Что только не делали с помощью IID. Даже самолёты. Ограничений на технологии не накладывает.
4. Величина рисков не зависит от методологии. Хотя использование незнакомых инструментов риски может породить. Зато убрать другие.
5. Scrum не произносится как "Скрум". Конечно, если вы не из Ланкашира, UK.
В общем, только хардкор, только факт-чекинг. Ну а изменений все боятся. Эт нормально.
Жила-была компания #СоусПарк.
Ну вы помните эту компанию: https://www.tg-me.com/cloveri/5
Однажды к HR-специалисту Вере пришел новый тим-лид Тарас и принес требования к двум вакансиям — подобрать программистов. Но вместо «Принято, пойду искать», услышал странный вопрос: «Зачем?».
– Что «зачем»? — спросил Тарас.
– Зачем тебе эта вакансия?
– Как зачем? От нас программист ушел. Вот я и принес требования к новому.
– А почему требования именно такие? — продолжила вопросы Вера.
– Я скопировал с другой нашей вакансии — ответил Тарас.
Кажется, что Тарас всё сделал правильно? Ведь в компании уже есть похожая вакансия, требования к ней написаны. Уже понятно, что человек должен знать о предметной области, что должен знать про практики и инструменты. Зачем что-то выдумывать, если можно пропустить этот шаг?
Да, но нет.
Следующий вопрос Веры был такой:
Что на _самом деле_ потеряла команда с уходом программиста?
Какие компетенции пропали из компании? Знание конкретных инструментов разработки? Практика работы по гибким методологиям? Опыт проектирования высоконагруженных систем? А какие из этих компетенций ключевые?
Осознанность при составлении вакансии — большее ускорение, чем копирование требований. Чем лучше вы понимаете, какие именно компетенции провалились, тем точнее ваш HR-специалист определится с тем, как выглядит кандидат. Где он водится и как его привлечь в компанию. На что обращать внимание при оценке, а что можно выпустить из фокуса.
Вера умная. Будьте как Вера.
В следующей серии — про вторую вакансию Тараса.
В ФБ: https://www.facebook.com/WebByte/posts/1918163988248338
Ну вы помните эту компанию: https://www.tg-me.com/cloveri/5
Однажды к HR-специалисту Вере пришел новый тим-лид Тарас и принес требования к двум вакансиям — подобрать программистов. Но вместо «Принято, пойду искать», услышал странный вопрос: «Зачем?».
– Что «зачем»? — спросил Тарас.
– Зачем тебе эта вакансия?
– Как зачем? От нас программист ушел. Вот я и принес требования к новому.
– А почему требования именно такие? — продолжила вопросы Вера.
– Я скопировал с другой нашей вакансии — ответил Тарас.
Кажется, что Тарас всё сделал правильно? Ведь в компании уже есть похожая вакансия, требования к ней написаны. Уже понятно, что человек должен знать о предметной области, что должен знать про практики и инструменты. Зачем что-то выдумывать, если можно пропустить этот шаг?
Да, но нет.
Следующий вопрос Веры был такой:
Что на _самом деле_ потеряла команда с уходом программиста?
Какие компетенции пропали из компании? Знание конкретных инструментов разработки? Практика работы по гибким методологиям? Опыт проектирования высоконагруженных систем? А какие из этих компетенций ключевые?
Осознанность при составлении вакансии — большее ускорение, чем копирование требований. Чем лучше вы понимаете, какие именно компетенции провалились, тем точнее ваш HR-специалист определится с тем, как выглядит кандидат. Где он водится и как его привлечь в компанию. На что обращать внимание при оценке, а что можно выпустить из фокуса.
Вера умная. Будьте как Вера.
В следующей серии — про вторую вакансию Тараса.
В ФБ: https://www.facebook.com/WebByte/posts/1918163988248338
И снова про осознанность при подборе. Возвращаемся в #СоусПарк
Итак, если ищете кого-то на замену, хорошие вопросы — Какие компетенции на самом деле потеряла команда с уходом специалиста?. Что мы хотим восполнить?
Но что спрашивать, если команда растет?
...Оторвавшись от монитора HR-специалист Вера взглянула на тим-лида Тараса.
– Тарас, вторая вакансия — это тоже замена кого-то из ушедших сотрудников?
– О, нет! Мы растем! Нам нужны еще программисты! – ответил Тарас.
– Зачем?
– Ну... Э... Потому что нужно быстрее выпускать релизы. Быстрее доставлять пользователям продукт.
– Тарас, вспомни Брукса. — попросила Вера. — В своей книге «Мифический человеко-месяц» он писал, что добавление людей в проект не всегда приводит к ускорению. Почему ты считаешь, что в нашем случае нужны именно программисты?
И действительно, почему мы открываем новую вакансию? Всегда ли нам нужно ускорить появление нового кода?
Что _на самом деле_ нужно команде?
Часто, причина в низкой скорости выпуска продукта — не количество разработчиков. Причин много. Вот лишь некоторые из них.
1. Дрейф требований
Заказчик не понимает, что он хочет. Вместо запуска продукта и получения обратной связи от реальных пользователей, постоянно меняет требования. В данном случае нужен не программист, а умение сказать: «Стоп. Давайте наконец-то выпустим продукт и получим фидбэк».
2. Неумение выпускать продукт небольшими порциями.
Вместо итерационной разработки мы месяцами готовим новый релиз и пытаемся приблизить сдачу добавлением людей. «Ресурсов», как говорят особо отмороженные PMы. В данном случае нужен навык инкрементального развития продукта, понимание практик создания MVP. Он точно у программиста?
3. Проблемы с процессами.
Прозрачности в работе нет, неясно кто и чем занят.
Нужен ли здесь программист? Да нет, конечно. Здесь нужен менеджер / скрам-мастер / хрензнаеткто с компетенцией выстраивания нормальных рабочих процессов.
4. Сложная, запутанная архитектура продукта.
Десятки зависимостей. Хочешь сделать фичу, а она сразу затрагивает биллинг, веб-интерфейс, личный кабинет, хрензнаетсколькоещекомпонентов. Кто нужен здесь? Скорее, архитектор. Который сможет отрефакторить архитектуру.
Не факт, что при росте команде нужен именно тот специалист, за которым пришел заказчик. Возможно, узкое место в поставке продукта — в какой-то иной компетнции.
Правильные вопросы — компас, который поможет HR-специалисту двигаться в нужном направлении, не терять время.
В чем ограничения команды? Кто ей нужен _на самом деле_?
Итак, если ищете кого-то на замену, хорошие вопросы — Какие компетенции на самом деле потеряла команда с уходом специалиста?. Что мы хотим восполнить?
Но что спрашивать, если команда растет?
...Оторвавшись от монитора HR-специалист Вера взглянула на тим-лида Тараса.
– Тарас, вторая вакансия — это тоже замена кого-то из ушедших сотрудников?
– О, нет! Мы растем! Нам нужны еще программисты! – ответил Тарас.
– Зачем?
– Ну... Э... Потому что нужно быстрее выпускать релизы. Быстрее доставлять пользователям продукт.
– Тарас, вспомни Брукса. — попросила Вера. — В своей книге «Мифический человеко-месяц» он писал, что добавление людей в проект не всегда приводит к ускорению. Почему ты считаешь, что в нашем случае нужны именно программисты?
И действительно, почему мы открываем новую вакансию? Всегда ли нам нужно ускорить появление нового кода?
Что _на самом деле_ нужно команде?
Часто, причина в низкой скорости выпуска продукта — не количество разработчиков. Причин много. Вот лишь некоторые из них.
1. Дрейф требований
Заказчик не понимает, что он хочет. Вместо запуска продукта и получения обратной связи от реальных пользователей, постоянно меняет требования. В данном случае нужен не программист, а умение сказать: «Стоп. Давайте наконец-то выпустим продукт и получим фидбэк».
2. Неумение выпускать продукт небольшими порциями.
Вместо итерационной разработки мы месяцами готовим новый релиз и пытаемся приблизить сдачу добавлением людей. «Ресурсов», как говорят особо отмороженные PMы. В данном случае нужен навык инкрементального развития продукта, понимание практик создания MVP. Он точно у программиста?
3. Проблемы с процессами.
Прозрачности в работе нет, неясно кто и чем занят.
Нужен ли здесь программист? Да нет, конечно. Здесь нужен менеджер / скрам-мастер / хрензнаеткто с компетенцией выстраивания нормальных рабочих процессов.
4. Сложная, запутанная архитектура продукта.
Десятки зависимостей. Хочешь сделать фичу, а она сразу затрагивает биллинг, веб-интерфейс, личный кабинет, хрензнаетсколькоещекомпонентов. Кто нужен здесь? Скорее, архитектор. Который сможет отрефакторить архитектуру.
Не факт, что при росте команде нужен именно тот специалист, за которым пришел заказчик. Возможно, узкое место в поставке продукта — в какой-то иной компетнции.
Правильные вопросы — компас, который поможет HR-специалисту двигаться в нужном направлении, не терять время.
В чем ограничения команды? Кто ей нужен _на самом деле_?