Управление разработкой *

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

В этом блоге мы много пишем про разработку и продвижение приложений. Настало время для взгляда с другой стороны. В середине ноября наши друзья из Sports.ru запустили курс по продакт-менеджменту мобильных приложений. Среди лекторов – сотрудники Sports.ru, AppFollow, Aviasales, Uber и другие классные ребята. Весь декабрь студент курса kirillkobelev будет рассказывать, как проходит обучение и что же нужно знать юному продакт-менеджеру, чтобы создать лучшее мобильное приложение. Передаем слово автору:

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

Мы в 1cloud считаем, что программисты очень похожи на художников. Так же, как и в сфере искусства, IT-специалисты часто мыслят творчески. И хотя искусство нельзя загонять в какие бы то ни было рамки, правильная постановка задач, мотивация и контроль помогут удержать функционирование компании на плаву.

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

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

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

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

Гвидо ван Россум известен как создатель языка Python. С момента создания языка Гвидо многократно награждался различными премиями. В 2001 году он получил награду за вклад в развитие свободного программного обеспечения от 'Free Software Foundation', а в мае 2003-го удостоился премии 'NLUUG Award'. В 2006 году ему присвоили звание Выдающегося Инженера.

Свободное от работы время Гвидо уделяет семье и самообразованию. Он большой фанат сериала 'Летающий цирк Монти Пайтона' (Monty Python's Flying Circus), именно в честь этого шоу и был назван язык программирования Python.

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

Проходя собеседование на должность руководителя разработки в некоторых компаниях, автору в ходе разговора приходилось выслушивать одну и ту же историю:

«Есть у нас 3 — 4 программиста, которые вот уже полгода (или год — период времени зависел от компании) “пилят” один проект. Тем не менее, несмотря на усилия, работоспособной “демки”, которую можно запустить и продемонстрировать Заказчику, все еще нет. Мы ищем руководителя, который смог бы организовать работу».

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

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

Обо мне

Я работаю в сфере разработки программного обеспечения 28 лет. Моя нынешняя должность — старший директор по развитию программного обеспечения консалтинговой компании в Остине, штат Техас. Я работаю на этой должности чуть более шести лет.

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

Во Вселенной работает довольно жестокий вид кармы.

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

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

Сегодня день рождения одного из отцов-основателей Agile-манифеста — Алистера Коберна. Предлагаю вашему вниманию перевод его выступления на TED про командную разработку.



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

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

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

Статья Джоэла о Пяти мирах (программного обеспечения) вышла в 2002 году. За прошедшие 14 лет успели образоваться новые миры: Мобильные приложения и Облака, — но соль статьи осталась неизменной.

Одна и та же технология в разных условиях будет давать разную эффективность.

Когда мы обсуждаем опыт применения какой-то технологии, мы часто не обращаем внимания на контекст её применения из-за этого возникает недопонимание, неверное толкование и применение технологий.
 
Представьте, мы на Земле, наш друг Марк на Марсе. У нас стоит одна и та же цель, вырастить в своём Мире урожай картошки. Технологию будем использовать одинаковую «посадка в грунт», а результаты получим разные так как влияние факторов/переменных разное для каждого из Миров. Это кажется очевидным, но факты из жизни говорят об обратном.

Информационные технологии наконец добрались до рынка продажи билетов на культурно-массовые мероприятия. Еще несколько лет назад в России не существовало ни одного онлайн-агрегатора билетов на подобные мероприятия.

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

Но теперь эта ниша не пустует благодаря нескольким энтузиастам. Егор Егерев, CEO и основатель билетной платформы Tickets Cloud поделился с нами своим опытом запуска и развития онлайн-сервиса с системой продажи электронных билетов «в едином билетном поле». Более того, он дал несколько советов начинающим.

Про Scrum часто можно услышать фразы вроде «православный Scrum», «мы используем best practices из Scrum» или «что почти всегда остается» от техник Scrum при его реализации.

Говоря это, подразумевают, что Scrum — это некоторая эзотерическая методика, которая неприменима в реальной жизни по той или иной причине. Например потому что «для скрам нужно очень много бабла, а мы должны жить по средствам» или «в Scrum разработчики должны быть супер универсальными, а у нас таких нет». А раз так — делается вывод, что «нужно думать головой», и все нужно делать по-своему. В результате такого подхода в рабочем процессе появляются некоторые улучшения, но в целом ничего не меняется, что еще больше убеждает в том что Scrum — это фантазии не имеющие отношения к реальному миру. Это не так.

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

» Черновик перевода я оставил на GitBooks (просьба все правки по переводу добавлять прямо туда).
» Скомпилированная и готовая к боевому использованию версия документа может быть найдена тут.
» Оригинальная версия всё еще лежит здесь.

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

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

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

Как это возможно и какие технологии меняют мир спорта? Попробуем разобраться.

Откуда берутся идеи для новых продуктов? Эволюция и стадии развития идеи. Каковы принципы формирования проектной команды? Инструменты стимулирования новых идей. Обо всем этом мы рассказывали на минувшем форуме RIW/16. В этой статье любезно подготовленной Марией Кигель для портала Mediajobs.ru вы найдете выдержки из выступления Елены Корякиной, директора департамента облачных технологий компании Parallels. Кстати, презентация доступна по ссылке.

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

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

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

Делимся опытом создания технологичного сайта. Крупная строительная компания Mizol обратилась в WebProduction с задачей создать корпоративный сайт. Mizol на рынке Украины с 1994 года. На счету 900 000 проектов. Чтобы создать сайт соответствующий требованиям и целям заказчика пришлось потрудиться.

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

***

Я расскажу историю одного тестового задания. Немного длинную, но, надеюсь, интересную.

У нас в Ecwid все тестовые задания для инженеров выложены открыто на GitHub вот тут — github.com/Ecwid/new-job. Можно просто начать делать любую понравившуюся задачу, никого не предупреждая, а потом, когда сами будете довольны результатом, поделиться им со мной.

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

Качальщик нужно сделать действительно очень примитивный. Судите сами — ты ему список ссылок в текстовом файле, а он скачивает эти файлы и кладет в указанную папку на локальном диске. Должен уметь качать несколько файлов одновременно (в несколько потоков, например, 3 потока) и выдерживать указанное ограничение на скорость загрузки, например, 500 килобайт в секунду. Всё.