IT-беседка

🤖 Живые киборги: Кибер Моторика

На этой неделе в Сколково нас познакомили с компанией Кибер Моторика. Ребята делают очень крутое дело: создают протезы конечностей. Занимаются этим еще с 2013 года и теперь уже выпускают на собственном производстве 250 протезов в месяц. Внедряют распознавание на основе ИИ и разрабатывают новые датчики.

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

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

#интересное

🔤🔤🔤🔤🔤🔤🔤🔤
Наш проект в преакселлераторе Сколково

На днях наш проект Белая Ворона прошел в преакселлератор Сколково. С вводной встречи поснимала для вас немного на территории технопарка.

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

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

В комментариях пишите про что рассказать в первую очередь ⬇️

Как формируется лидерство: моя история

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

Как я управлял запуском без должности руководителя
Первый свой крупный проект я запускал в Рамблере будучи разработчиком. Тогда мы были в группе RDS с идей быстро запускать и развивать новые направления. Первую версию проекта Путешествий мы сделали меньше чем за месяц, а вот сопровождение всего было все еще частью старой структуры и они еще даже не начали готовить наши сервера. И, в общем, тут бы и сказке конец, ждем и надеемся. Но я обошел все руководство, до которого дотянулся, включая свое направление бизнеса, и мне выдали людей, с которыми мы к 4 часам ночи запустили наш проект. Руководитель, который был в команде, от этой задачи устранился со словами, что лучше подождать. Может лучше, может нет - выбирает каждый сам. Была цель, были найдены возможности, ни должностей ничего тогда у меня не было, лишь умение настаивать на своем. Причем довольно однобоко и топорно на тот момент. Это сейчас уже у меня есть готовый алгоритм, как что-то запустить с помощью ситуационного лидерства, который я описывал в нашем руководстве по борьбе с рутиной, тогда еще я действовал больше интуитивно.

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

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

Максим Шаламов
#руководителю #разработчику #советы

Как скинуть балласт – избавляемся от нерадивого сотрудника

Итак, в вашу команду, не смотря на все ваши старания, попал нерадивый сотрудник. Вы уже все перепробовали и наконец решились на его увольнение. Что делать дальше?

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

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

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

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

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

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

Максим Шаламов
#руководителю

Самая недооцененная проблема проекта

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

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

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

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

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

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

Максим Шаламов
#риски

Почему задача обязательно должна быть маленькой

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

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

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

Возможность управлять эффективностью
Один из очень важных плюсов маленьких задач - возможность правильно вести статистику работы команды. Если команда работает по итерациям (а вы знаете, что так лучше), то задачи, которые укладываются в итерацию, дают возможность точно посчитать какой объем работы сделала команда (те, кто читал нашу книгу по процессам уже знают, как это делать). Так вы четко следите за снижением и повышением эффективности команды и можете вовремя реагировать на эти изменения. А если команда ушла в работу на 2 или, не дай Бог, 6 месяцев, делая одну задачу, вы по сути останетесь в слепой зоне и узнаете о проблемах в команде уже слишком поздно.

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

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

Александра Шаламова
#agile_который_работает