Рубрика «управление разработкой» - 2

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

Меня зовут Александр Шиндин, я — технический менеджер мобильных продуктов Kaspersky Password Manager и Kaspersky Who Calls. Я так сильно хотел проявить себя в роли руководителя, что внутренних обучающих курсов, которые дает в таких случаях компания, мне не хватало, — и лучшим дополнением к теории стали книги. Они ускорили мое погружение в мир менеджмента, помогли быть готовым к еще большему числу нестандартных ситуаций и придали уверенности в принимаемых решениях.

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

«Я стал тимлидом и боюсь». Что почитать и зачем - 1
Читать полностью »

На скриптовых языках удобно разрабатывать… И на этом удобство заканчивается. Вне машины разработчика начинаются проблемы. Особенно если вы пишете какой-то прикладной тулинг — cli-утилиты, вспомогательные приложения в вашем SDK и прочее. Вы даже не можете рассчитывать на то, что у пользователя будет pip, чтобы он смог поставить все ваши зависимости, вам все нужно организовать самостоятельно.

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

Читать полностью »

Причины «имитации работы» в Big Tech - 1


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

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

Столкнувшись с угрозой увольнения, Грэг, наконец, пришёл в проект по применению машинного обучения для улучшения рекомендаций музыки Amazon, который, по его мнению стал «первой по-настоящему интересной задачей, над которой мне довелось работать». Он был счастлив ощущать себя ценным членом команды, но его менеджер сообщил ему нечто поразительное: готовый проект, над которым Грэм работал больше месяца, никогда не будет выпущен. Ему сказали, что это было просто занятие, чтобы соответствовать условиям его плана контроля производительности и продления срока его найма. Вскоре после этого Грэм уволился из Amazon.
Читать полностью »

Самое сложное в ПО — не кодинг, а требования, или Почему разработчикам не стоит бояться ИИ - 1


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

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

В этой статье я расскажу о связи между требованиями и ПО, а также о том, что необходимо ИИ для создания хороших результатов.
Читать полностью »

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

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

Читать полностью »

В недавнем прошлом многие IT-команды применяли в разработке линейку продуктов от Atlassian: Confluence, Jira и Bitbucket. Полноценный цикл разработки включал в себя до 70 различных операций и процессов: удобно, когда их можно реализовать в единой экосистеме.

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

image

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

Монолит или микросервисы — это не вопрос технологических предпочтений, это про time-to-market - 1 На конференциях эта тема (монолит vs микросервисы) обсуждается с завидной регулярностью, но обычно в техническом ключе. Кто-то любит консистентность монолита, кто-то гибкость микросервисов, какие-то инструменты удобнее, какие-то нет.

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

Поехали.

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

Одна команда

Когда команда одна, не очень большая (two pizza team), то никто никому не мешает. Код ревью, рефакторинг, деплой проходят быстро и весело. Бизнес сфокусирован на цели и работает как единое целое. Целью, кстати, зачастую является проверка гипотезы, нужен ли вообще этот проект кому-то или нет.

Читать полностью »

Время «рок-звёзд»: когда разработка ПО основывалась на талантах и креативности - 1

Впервые за 5 лет в отпуске на Гватемале. Заканчиваю эту статью

В качестве саундтрека для этого поста я выбрал песню Torn Натали Имбрульи.

Какие статьи у нас выходили после «Куда подевались все хакеры?» Самое масштабное из того, что помню – это прекрасная серия Software and its Discontents за авторством Келлана, в которой он постарался ответить на вопрос «Почему сегодня все так недовольны ПО?»

Мне та серия очень понравилась, но при этом я чувствовал, что она не раскрывает всеобъемлющий контекст, стоящий за всеми описанными в ней мрачными чувствами: «Разработка прикладного ПО больше не является игрой талантов и креативщиков. Теперь это превращённая в коммерческий товар муть с прописанными правилами для её создания». Эти правила описывают игру, которая: а) не вызывает у большинства участников интереса и мотивации, b) больше основана на управлении рисками (страхе), чем на максимизации результата (надежде) и с)… похоже, на деле не особо работает? Если же ты вдруг отклоняешься от этих правил, то на тебя все начинают кричать, называя незрелым или несерьёзным.Читать полностью »

Доводите свои проекты до конца - 1


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

Но рано или поздно вдохновение сменяется чем-то больше похожим на… работу. На рутину. Но ведь так будет только с этим проектом, правда? Вы потеряли интерес. Страсть ушла. Он уже не такой интересный, как вы думали. Осталось сделать только самое «скучное».

У вас появляется новая идея, и вы думаете, что эту-то уж точно реализуете!

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

Но не волнуйтесь, вы не один. На самом деле, вы, скорее, в большинстве! Многие люди мечтают создавать что-то великое, но никак не могут начать. Из тех немногих, кто начинает, очень немногие заканчивают. И эти несколько людей знают чувство глубокого удовлетворения от того, что видят готовый результат своей работы. Это удовлетворение намного глубже, чем эйфория начала проекта.
Читать полностью »

Я начинал карьеру как фронтенд-разработчик и прошел по всем стандартным этапам: от джуниора до сеньора и тимлида, потом стал руководителем отдела. И дальше, конечно, планировал стать CTO. И только через несколько лет узнал, что мои представления о том, какие навыки нужны на этой должности, были далеки от реальности.

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

Читать полностью »

https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js