Connect with us

Разработка

Григорий Петров: Управление разработкой. Сороковая колонка

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

Григорий Петров

Опубликовано

/

     
     

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

Колонка 31: Как повелевать знаниями

Почти двадцать лет я пишу софт. И пока не видел ни одной программы, в исходный код которой удалось бы поместить всю относящуюся к ней информацию. Не влезает. Исходный код – он для описания “что и как делается”. А информации намного больше: “зачем делается”, “почему делается так, а не иначе”. Чтобы ценная информация не потерялась, ее последовательно пытаются запихнуть сначала в код, затем в комментарии к коммитам, затем в комментарии к коду, и, если совсем никуда не влезает – в отдельную систему управления знаниями. У которой есть свои плюсы, минусы и неожиданные бонусы, о которых и рассказано в колонке.

Колонка 32: Где найти тим лида?

Танк, хилер и дамагер Продукт, проджект и тим лид – три роли в команде разработки, которые нередко совмещают в одном человеке. Про роль тим лида я уже писал. А в этой колонке речь идет о том, где искать такого человека. Хорошие признаки тим лида: любовь организовывать процессы и выступать на конференциях. Кстати, конференции – хорошее место для поиска такого бойца. А спрашивать его лучше всего про процессы: “как вы организовали”, “как проверяли”, “как защитите”. Ну и мое любимое: “Разработчик, отвечающий за релизы, заболел и лежит в больнице. Нужно к завтрашнему утру собрать брендированную версию продукта. Ваши действия?”. При этом смотреть лучше всего не на ответ, а на подход: о чем кандидат будет говорить в первую очередь, какие вопросы и в каком порядке задавать.

Колонка 33: Ползучий фичеризм

Человеческий мозг постоянно строит модели, пытаясь самым простым способом объяснить окружающий мир. Программы – не исключение. И разработчик, и заказчик, не зная как делать правильно, будут постоянно чувствовать потребность все поменять и “сделать по уму”. Такое фонтанирование идеями, постоянная переделка и “улучшения” программного обеспечения имеет имя. Это имя – “ползучий фичеризм”. По имени можно догадаться, что ничего хорошего оно не обозначает. Почему фичеризм именно ползет, а не бежит? Куда он ползет? Какой вред наносит? Обо всем этом написано в колонке.

Колонка 34: Как и зачем читать чужой код

Чтобы действительно понять чужой нетривиальный код, нужно понять, как работает разум другого человека плюс провести реверсию Кошелька Миллера – разбить картину на последовательность мазков и эскизов, иначе оно просто не влезет в фокус внимания. Странный вывод: если действительно внимательно читать чужой код, то вам для этого потребуются либо уникальные люди (я таких встречал, одного человека) либо опытный разработчик будет тратить на чтение чужого кода примерно столько же времени, сколько автор потратил на его написание. Контринтуитивный секрет code review: не нужно внимательно читать все. Опытные разработчики, делая code review, быстро просматривают код в поисках подозрительных моментов, не пытаясь понять каждую строчку и разобраться в хитросплетениях борьбы автора со сложность. Если что-то привлекло внимание – то на это смотрят внимательнее. Если нет – специально не ищут. Действительно опасные проблемы с архитектурой и скопления сложности видны опытному разработчику сразу. Остальное покажу тесты. У вас ведь есть тесты?

Колонка 35: Зачем программисту выступать на конференциях

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

Колонка 36: Утренний стендап

Если разработчик привык решать задачи за несколько часов и у него случается “затык”, то тим лид может слушать “сейчас, уже почти-почти все готово” на протяжении недель. Не потому что разработчик плохой или глупый. А потому что автоматика. Если разработчик привык писать код сам, то ему никогда не придет в голову искать open source решение, даже если самому писать месяц, а чужую библиотеку прикрутить можно за день. И снова – не потому что разработчик плохой или глупый. А потому что автоматика. Хороший способ борьбы с автоматикой – правильно организованный утренний стендап. Это практически эталонный образец коридора: он создает такие условия, при которых участникам команды очень легко делать правильные вещи. И очень трудно делать вещи неправильные.

Колонка 37: Зачем задавать вопросы на Stack Overflow

Подготовка и выступление на конференциях – не единственный способ борьбы с некреативностью нашего воображения. Еще одна хорошая тренировочная площадка – это Stack Overflow. Причем не в той его части, где на вопросы отвечают. А в той, где вопросы задают. Оказывается, грамотно сформулировать вопрос на Stack Overflow – это такое выступление на конференции в миниатюре. Чтобы на вопрос ответили, он должен быть хорошо сформулирован: понятным языком, с уточнением всех деталей и минимальным примером кода. Сбор всей этой информации и написание текста вопроса полезны как тренировка. Бесплатный бонус: очень часто в процессе формулирования вопросы мы сами находим ответ.

Колонка 38: Синдром «Not Invented Here»

Многие из нас сталкивались с ситуацией: приходит тим лид к разработчику, говорит, что нужно выбрать какую-нибудь библиотеку. Разработчик честно смотрит варианты, после чего отвечает: это все не то, надо самим писать. И ведь пишут! Пишут, даже если использовать готовое – это день, а писать самому – это месяц. Если повезет. Пишут, несмотря на срыв сроков и риски. У такого подхода есть название: синдром “придумано не нами”, или же “not invented here syndrome”. Сокращенно – NIH. Известное когнитивное искажение, особенно широко распространено в разработке софта. По двум традиционным причинам, о которых я не устаю писать в каждой второй статье: мы пока не знаем как “правильно” писать код и у нас отсутствует фундаментальное образование для разработчиков.

Колонка 39: Системы управления задачами

Мы запоминаем не то, что было на самом деле, а то, что укладывается в нашу картину мира. А потом перезаписываем свежими впечатлениями раз сто. Поэтому разработчик запомнит не задачу, а то, что “приходил тим лид, ругался”. Через неделю поверх перезапишутся его собственные идеи по развитию продукта, разговоры коллег, общение с тим лидом – и в результате, когда руки дойдут писать код, память предложит разработчику совсем не то, что ожидает тим лид. Использовать трекер для работы с задачами – контринтуитивно. Если до этого разработчик, к примеру, записывал все на бумажках или полагался на свою память и письма в аутлуке – то весь его жизненный опыт будет бунтовать против “новой, непонятной, ненужной работы”. Чтобы побороть естественное сопротивление нашего мозга ко всему новому и “ненужному”, работу с задачами удобно возвести в ранг ритуала. Нет тикета? Нет задачи. Тикет не отрезолвлен? Задача не выполнена. Так же как со стендапом, о правилах игры нужно договориться заранее и строго их придерживаться – только в таком случае наш мозг проникнется серьезностью момента, и не будет пытаться “обмануть систему”.

Григорий Петров
Комментарии Facebook
Продолжить чтение
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Обучение

Разработка iOS 11 приложений на Swift

Стэнфордский университет опубликовал новую версию курса по Swift в iTunes U.

Леонид Боголюбов

Опубликовано

/

В новом курсе учтены все изменения, сделанные в iOS 11 и новой версии Swift.

Темы:

  • Инструменты и API, которые понадобятся для разработки приложений для iPhone и iPad/
  • Пользовательский интерфейс.
  • MVC-парадигма.
  • Анимации.
  • Многопоточность.
  • Работа с сетью.

Курс бесплатен и доступен для прохождения на iPhone и iPad. Язык – английский.

 

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Новости

Интересные материалы: 16.11

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

Леонид Боголюбов

Опубликовано

/

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

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Разработка

Почему не надо патентовать идею мобильного приложения

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

AppCraft

Опубликовано

/

Автор:

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

В этой статье мы тезисно перечислим причины этого не делать.

Что такое патент

Патент – это охранный документ, удостоверяющий исключительное право, авторство и приоритет изобретения, полезной модели либо промышленного образца. В случае с разработкой мобильного приложения, являющегося программным обеспечением, получить патент в России и Европе на алгоритмическую часть (непосредственно программу) не удастся: статья 52 европейской патентной конвенции прямо запрещает патентование программ для ЭВМ.

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

Это долго и дорого

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

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

Вы потратите минимум 50–100 тысяч рублей (если часть работы будете делать самостоятельно) и не меньше 3–4 месяцев, если делать все очень быстро.

После этого вы можете получить отказ на регистрацию от патентного бюро, потому что описание недостаточно детальное, не содержит инновационности, дублирует уже существующие патенты и т.д. Только 56% патентов регистрируется, соответственно, 44% – отклоняется.

При этом, по статистике, 97% (!) патентов генерируют прибыли меньше, чем стоимость их оформления.

Вы патентуете не то, что нужно

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

Пол Грэм, один из известнейших предпринимателей в IT и основатель Y Combinator, говорит, что по его опыту от 70 до 100% проектов имеют разные ключевые идеи на старте и через 3 месяца операционной работы.

Так происходит из-за того, что бизнес – это решение реальных проблем. Он развивается и растет в синергии с потребностями людей, которые:

  1. вам досконально неизвестны на стадии идеи;
  2. меняются со временем;
  3. решаются так, как хочется им, а не вам.

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

Забывается главное

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

Фокусируясь на защите идеи, вы сразу же отстаете в скорости ее развития и реализации.

Патент – не единственный способ защититься

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

  • Купите домен с именем продукта. Хорошее имя дает сильный эффект, а при решении любых споров покупка вашего домена в более ранний срок, чем оформление торговой марки конкурента, решает многие вопросы.
  • Создайте группы в социальных сетях с названием проекта. Как и в случае с доменом, хорошие названия имеют и хорошие поисковые позиции, и неплохо запоминаются, и становятся недоступны конкурентам.
  • Зарегистрируйте торговую марку. Это не быстро в некоторых юрисдикциях (например, в России), но во многих странах осуществляется в течение нескольких дней и с минимальными затратами.

Итого

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

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

AppCraft
Комментарии Facebook
Продолжить чтение

Календарь

ноябрь

17ноя - 19Весь деньТИЛТЕХ МЕДХАК

24ноя - 26Весь деньWhat the hack?!

25нояВесь деньSmart Taler 2017

25нояВесь деньLadies Code: время технологий

30нояВесь деньSmart Cars & Roads 2017

декабрь

5дек18:30- 22:00Яндекс изнутри: глазами iOS-разработчика

8дек - 9Весь деньКубок СTF России

9дек - 10Весь деньGames Gathering 2017

9декВесь деньЛекционный день по игровой индустрии

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков веб и мобильных приложений!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Наш Facebook

Популярное

X

Спасибо!

Теперь редакторы в курсе.