Люди очень часто неправильно думают про статический анализ кода.
Часто можно встретить такое мнение, выраженное в следующем абзаце:
У нас большой проект. В нем работает несколько десятков (сотен) программистов. То есть тот самый, про который вы пишите, что нужен статический анализ. Я скачал анализатор кода, выполнил проверку и нашел очень мало ошибок. Очевидно, что анализатор кода просто бесполезен!
Умоляю, уберите скорее от экранов перфекционистов и беременных своей чудесной идеей заказчиков. Пост содержит боль. И вообще, проконсультируйтесь с вашим психотерапевтом.
Читать полностью »
Директор Акселератора ФРИИ Дмитрий Калаев рассказал на онлайн-конференции «Как построить бизнес на основе технологии» о типах конкурентных преимуществ технологичных стартапов, как сформулировать ценность и конкурентное преимущество, которые помогут в продаже продукта клиентам, и в какой момент компании стоит задуматься о масштабировании.
Читать полностью »
Всем привет!
Сегодня я хочу рассказать о нескольких практиках оценок задач, которые сложились в нашей команде за годы совместной работы. Я надеюсь, что статья будет полезна тем, кто только начинает свой путь в менеджменте, и особенно тем, кто работает по ватерфелу в "кровавом enterprise".
Эффективное планирование зависит от множества разных факторов: от качества оценки, проработки деталей решения, использованной методики планирования, правильной оценки рисков.
Для начала я расскажу о подготовительной части планирования – оценке задачи разработчиками. В нашей команде нам удалось, балансируя между бюрократией и жизненной необходимостью, разработать ряд практик, которые позволяют без лишних промедлений и размышлений превращать оценки в план работ.
Сегодня мне хотелось бы поведать вам историю о том, как мы определяли сайты, торгующие наркотиками в рунете, о масштабах проблемы, об опыте взаимодействия IT компании с Роскомнадзором, депутатами, различными палатами, и почему на это больше не хватает зла.
Читать полностью »
Пару лет назад я встретился с родственником. Мой бедный двоюродный брат (генеральный директор страховой компании) продался Agile Silver Bullet и сильно пожалел. Он сказал что-то вроде:
Это надувательство! Мы изменили весь рабочий процесс. Мы пригласили консультантов. Мы наняли этих мастер-PMов. И ничего не работает! Нет никакого результата. Нет никакой ответственности. Все, что я получаю — это отмазки.
Я забыл, как я ответил, но я знаю, как бы я ответил сегодня. Я бы нарисовал несколько картинок и даже не упомянул бы слово Agile. Существует несколько ключевых концепций, о которых мне нужно будет ему сообщить.
Читать полностью »
Мы в редакции «Нетологии» вместе с преподавателями курса «Руководитель digital-продукта» сделали подборку лучших книг для продакт-менеджеров. Возможно, какие-то книги покажутся вам знакомыми… что ж, это не баян, а классика :) А классику знать обязательно.
Чтобы понять, что читать, чтобы сделать свою работу максимально эффективной, прокачаться и начать жить счастливо, мы опросили четырех преподавателей курса и составили подборку лучших книг. Надеемся, вы найдете для себя несколько полезных книг из этой подборки, которых вы еще не читали.
В своей статье "Как написать хороший SLA", я поминал, что в SLA просто просится внести процедуру эскалации. Хочу сказать пару слов за эскалацию.
Эскалацию в IT, по-моему, мало кто понимает. В ITIL она как-то мутно определена. Соответственно и дальше, при попытках её внедрить, градус мутности только возрастает. Ни Гугл, ни Яндекс не помогают найти ничего вразумительного. Вместо того, чтобы объяснить эскалацию просто и понятно (как это сделаю я), авторы начинают вводить какие-то новые термины, указывать в чём различие между функциональной и иерархческой эскалацией (зачем вообще это?), вещать что-то про автоматическую эскалацию, ничего не объясняя и уводя в сторону. И при этом из контекста можно предположить, что эскалация — это то ли синоним передачи запроса другому исполнителю, то ли в другое подразделение, то ли привлечение дополнительных ресурсов, то ли повышение приоритета. А иногда я просто теряюсь понять смысл. Всё это вызывает лично у меня ощущение или "кручу-верчу, обмануть хочу", или банальной некомпетенции.
Особенно мило (не могу удержаться и не привести этот пример) выглядит автоматическая "эскалация" запроса на другой уровень поддержки, если (sic!) текущий исполнитель не успевает в заданный в SLA срок. То есть будучи исполнителем, принимаем запрос и держимся изо всех сил, ничего по нему не делаем, пока он не будет вот-вот уже почти просроченным, и… бац! — срабатывает автоматическая "эскалация", которая переназначает запрос на кого-то другого. Профит!.. Главное держать себя в руках и ничего не делать. Можно было бы от души посмеяться, но кое-где именно такую схему "эскалаций" и применяют, выдавая за лучшие практики IT!
Так что же такое эскалация, кому и зачем она нужна? Сейчас расскажу своё понимание, после которого Вы, как я надеюсь, полюбите эскалацию также, как и я. Держитесь крепче за стул.
Предлагаю читателям Хабра мой перевод статьи «44 урока управления технарями» Славы Ахмечета, сооснователя RethinkDB. В оригинальной статье используется термин «инженеры», но в контексте статьи я буду использовать также термин «технари» – более емкое, как мне кажется, с точки зрения русского языка слово, охватывающее профессии в сфере ИТ, частью которой я тоже являюсь.
Немного об оригинальном тексте. Статья была написана в 2014 году в личном блоге автора, в октябре 2016 компания RethinkDB не смогла выйти в прибыль и закрылась, о чем на Хабре писали тут и тут, а Слава поразмышлял об этом здесь.
В комментариях к статье я бы хотел, чтобы читатели дали свою оценку этим урокам и высказали свое мнение по вопросу, который будет задан в конце статьи.
Вот один из пользователей «следующего миллиарда»:
Когда вы делаете систему для заключения сделок между людьми по всему миру на блокчейне, это звучит как новое хипстерское приключение. В основном из-за слова «блокчейн», наверное. Напомню, мы делаем сервис, который позволяет заключать сделки людям на смарт-контрактах и имеет довольно простую систему арбитража без включения центральных систем. Это было в прошлом посте.
Теперь пришло время рассказать о том, какие возможные риски будут у такой системы в конце 2018 года на большом релизе. Если он случится.
Первое и главное — мы отбираем хлеб у очень-очень многих. 12–14 миллиардов долларов — рынок бирж фриланса, 135 миллиардов — аутсорса для розницы, 40 миллиардов — переводов и журналистики, 150 миллиардов — удалённого обучения и персональных консультаций, а ещё есть психотерапия, телемедицина и прочее-прочее прочее.
Это всё наш рынок, потому что вы можете найти в системе нужного человека и купить 15–20 минут его времени, чтобы он показал вам, как у них в Индонезии готовят рыбу, либо ответил на пару вопросов по C++. Ну, либо сделал для вас кран, что более вероятно. Мы трезво понимаем, что в ближайшие 3–5 лет больше 5% даже рынка фриланса не занять — но всё же угрозу мы создаём кое -для кого серьёзную.
