Я работаю ПМом в небольшой – порядка 50 человек – компании по разработке софта. Данная статья написана исключительно с целью – поделиться своими мыслями по поводу процессов управления людьми в команде и, в идеале, услышать комментарии профессиональных руководителей и разработчиков. Сразу оговорюсь, что я не затрагиваю другие аспекты управления
Поскольку работаю весьма недолго, около года, а до этого был программистом (прошёл все ступени от стажёра до архитектора), то в памяти ещё свежи те ошибки, которые осуществляли мои руководители, после которых, в лучшем случае, на душе становилось пакостно. Опять же, дисклеймер, написано всё это исключительно с целью обсуждения… Итак, начнём.

Из этой статьи вы узнаете, что распознавание даже коротких звуковых фрагментов в зашумленной записи — вполне решаемая задача, а прототип так вообще реализуется за 30 строчек кода на Python. Мы увидим, как тут помогает преобразование Фурье, и наглядно посмотрим, как работает алгоритм поиска и сопоставления отпечатков. Статья будет полезна, если вы сами хотите написать подобную систему, или вам интересно, как она может быть устроена.

Подборка ссылок на патентную информацию и поисковые ресурсы в интернете.
Версия 1.0. Будем дополнять.
Поделитесь в комментариях своими ресурсами. Будем благодарны и добавим в пост для удобства.

Сегодня мы представляем вашему вниманию адаптированную подборку инструментов (в том числе облачных) для разработчиков, которые позволяют создавать по-настоящему качественные проекты. Здесь представлены исключительно SaaS, PaaS и IaaS сервисы, предоставляющие бесплатные пакеты для разработчиков инфраструктурного ПО.

Как правильно оформить сотрудника? Сегодня работодатели привыкли выбирать между трудовым и гражданско-правовым договорами. Между тем, уже пару лет как появилась возможность взять на работу «дистанционного работника». Этот вариант имеет свои весомые преимущества: сотрудник не обязан постоянно сидеть в офисе, но остается на «коротком поводке» трудового договора. Давайте разберемся, подойдет ли такой вид сотрудничества именно вам, и поймем, как избежать возможных проблем.

Один технический специалист нашей компании PayOnline, которая занимается автоматизацией приема платежей, предложил перевести статью автора Pascal de Vink, который проработал тим-лидом уже 2 года. Когда Pascal только занял эту должность, оказалось, что ко многим вещам он был просто не готов. Эта статья поможет избежать многих ошибок на пути от разработчика к лидеру команды. Ниже идет непосредственно перевод.

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

Меньше заниматься разработкой

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

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

Попробуйте открутить назад все Ваши проекты и оцените реальное опоздание по ним.

Может оказаться, что задержки достигают просто гигантских значений.

Автор статьи видел проекты с задержкой сроков в 400% и 700%!

Бытует мнение, что разрабатывать программы без опоздания невозможно в принципе.

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

На момент оценки трудоемкости ТЗ есть не всегда. И даже если оно есть, фактор неизвестности всё равно продолжает играть огромную роль – ведь люди, к сожалению, действительно не провидцы, и каким бы подробным не было ТЗ, всё равно остаются моменты, скрытые от глаз.

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

Интересно, что сценарии (варианты) использования позволяют довольно точно оценить трудоемкость работ.

Практика показала, что можно достигнуть 20% точности (=%ошибки) при оценке. А ведь опоздание 20% это совсем не 700%, верно?

Как это сделать?

1. Вступление

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

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

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

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

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

Да, все это необходимо знать. Но при этом, понимание того, как должен выглядеть достойный код, обычно появляется уже при наличии практического (чаще в той или иной степени негативного) опыта за плечами. И при условии, что жизнь “потыкала” тебя не только в сочные образцы плохого кода, но и в примеры всерьез достойные подражания.

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

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

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

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

Я не знаю, откуда идут эти «тайные знания», но практически каждый «новичок» считает своим долгом «задавить» ценой своих конкурентов. Удачная ли это мысль — «давить» ценой вопреки всем обстоятельствам? Разберём некоторые стороны маркетинга, которые позволят отказаться от слишком низких цен.

Преимущество — это субъективное понятие, зависящее от потребности клиента.

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

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

И первый лайфхак – кликабельная картинка до ката, которая ведёт сразу внутрь публикации:

По следам недавнего топика «Обработка больших объемов данных в памяти на C#» представляю перевод упоминавшейся там статьи о структурах.

Структуры являются фундаментальными типами данных в C# и большинстве других современных языках программирования. По своей сути структуры просты, но вы можете удивиться, насколько быстро работа с ними может стать сложной. Чаще всего проблемы возникают, если вы должны работать со структурами, созданными в других языках и сохраненными на диске или полученными в результате вызова функций из библиотек или COM-объектов. В этой статье я подразумеваю, что вы знакомы с понятием структуры, умеете определять их и владеете базовыми навыками работы со структурами. Предполагается, что вы имеете представление о том, как вызывать API функции с использованием p/Invoke, а также что такое маршалинг. В случае неуверенности в своих знаниях вы можете обратиться к документации.
Множество техник, описанных в данной статье, могут быть расширены и применены к любым типам данных.

Наша команда растёт и успешно развивается с 2009-го года, при том, что преобладающее большинство сотрудников не ходят в офис. Они сидят в своих московских и питерских квартирах, львовских и харьковских дачах, минских и нижегородских домах, тайских кондо и турецких бунгало. Проводя очередную бизнес-встречу в красивом московском офисе с потенциальным клиентом мы неизбежно слышим вопрос: «А где у вас офис?». Мы отвечаем честно: «В Нижнем Новгороде, но вообще-то, большинство наших сотрудников туда не ходит, они работают из дома».
Наступает небольшая пауза, во время которой, скорее всего, заказчик представляет себе примерно вот такую картину:



За шесть с лишним лет работы мы столкнулись с небольшим количеством трудностей «удалёнки», и со значительно бOльшим количеством недоверия и мифов об удалённой работе. Книга Remote нас порадовала и как будто сказала «ребята, вы на правильном пути», но полезных советов по трудностям, к сожалению, не дала. Поэтому в этой статье я соберу те советы и решения, которые помогут не наступать на наши грабли и не изобретать велосипеды.

В отличие от типичной болтовни про стартаперов и инвесторов, эти советы требуют делать выбор. И зачастую этот выбор реально ставит в тупик.

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

1. MVP против «Идеального продукта»
1.1.
«Запуская проект, вы никогда не сможете заранее сказать, как отреагирует на него рынок. Ваше видение своего продукта является галлюцинацией. Не нужно фантазий. Стартуйте с MVP (минимальный жизнеспособный продукт) и дальше используйте Lean Startup (набор коротких итераций). Только так создаются все успешные компании. В итоге вы сами удивитесь, увидев созданный вами бизнес».



Ему вторит высказывание:

«Только пользователь или ваш клиент знает, что ему нужно. Наблюдайте за пользователями. Не диктуйте рынку своё мнение, а слушайте рынок. Повинуйтесь рынку, идите за ним как рыба-прилипала за китом».

Разрази меня гром, если этот совет неверен. Абсолютно все акселераторы стартапов проповедуют это принцип, он принят в 99% успешных компаний. Надо быть глупцом, чтобы не следовать этому совету. Однако:

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



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

Предисловие

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

В последнее время всё большую популярность набирают Wi-Fi модули на основе ESP8266. Я тоже решил приобщиться к прекрасному, задумав реализовать термометр, отдающий данные по HTTP. Итак, поехали.

Понадобилось мне слать SMS из ардуинины себе на телефон. Да так, что бы без заморочек с GSM, сим картами и оплатой. Под катом то, что из этого вышло.