IT-инфраструктура штабов Навального и сбор подписей: управление проектом

Cерия публикаций про сбор подписей

1. Введение, сайт «Навальный 20!8», подготовка к сбору
2. Железо и сети, видеонаблюдение
3. Жнец-2018: система для сбора подписей
4. Управление проектом

Это заключительная глава материала про IT-инфраструктуру штабов Навального. Здесь рассказывается про управление проектом и про участников проекта со стороны IT-отдела.




Работа над проектом


Подготовка к сбору подписей — долгий, сложный, ресурсоемкий и совершенно незаметный со стороны проект, который не приносит штабу и кандидату никаких «политических очков», а в случае отказа в регистрации оказывается совершенно ненужным. Почему мы решили инвестировать в него такое количество денег, времени и усилий? Читать дальше →

Satisfaction по-джетовски, или как мы управляем удовлетворенностью заказчиков



В начале 2016 года наш Сервисный центр — один из крупнейших в России и СНГ — начал применять методику под названием «процесс управления удовлетворённостью заказчиков качеством услуг». С тех пор прошло уже два года, мы накопили опыт и статистику, и сегодня готовы рассказать, что же дал нам и нашим клиентам этот рабочий процесс.
Читать дальше →

Обзор лучших докладов с HighLoad++ 2017

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

Goth2Boss: ломка и отходняки при переходе из инженера в тимлиды / Артем Каличкин




Для меня это открытие года — на мощной технологической конференции первое место занимает доклад, хоть и от технаря, но про УПРАВЛЕНИЕ. Конечно можно рассуждать на тему того, что гуманитарии более охотно ставят оценки и по-умолчанию более лояльная аудитория, но факт остаётся фактом.
Читать дальше →

Культура использования ПО в компании

У студентов начала XXI века была излюбленная отмазка: «У меня жёсткий диск полетел, а на нём как раз осталась дописанная курсовая». Пожалуй, это была одна из немногих проходивших причин. Но за этим враньём скрывается очень важный синдром современного общества — валить вину на технику. ДТП — электрика заглючила, отчёт не сдан — компьютер завис, проект не завершён — что-то всё тормозит, письмо забыли отправить — что-то с почтой, прозвонили по дублям — CRM тупит и т.д. Никакой культуры использования технологий. А какая она вообще должна быть, эта культура и как она соотносится с корпоративной культурой в бизнесе? Давайте поспорим — это огромный простор для дискуссии.


Когда рабочий софт не оставляет равнодушным
Читать дальше →

Рассуждения вокруг системотехники и комментарии к «Ричард Хэмминг: Глава 28. Системная Инженерия»



Попытался прокомментировать статью Ричард Хэмминг: Глава 28. Системная Инженерия» через свое понимание проблем «системной инженерии» и с учетом «современности», а также связанных или даже частично дублирующих ее EA \ BPM.
Выдержки из оригинала показаны цитатами, из других источников – курсивом. Плюс рассуждения вокруг системотехники.

Системная инженерия или Systems engineering (SE) – также давно известное направление, как и BPM (Business Process Management) и EA (Enterprise Architecture). Найти, где заканчивается SE и начинаются ЕА и ВРМ – сложно. Уж очень все эти три направления «по-развивались», особенно в маркетинговой плоскости.

Любое проектирование «большого и сложного» — должно базироваться на SE. Проектирование предприятия (а это и есть сложная система), описание архитектуры предприятия – это не SE? В стандартах SE часто употребляется и «предприятие» и «архитектура». Выделяют даже отдельное направление Enterprise Systems Engineering (ESE)
Читать дальше →

Просыпаешься, а твое приложение на главной в App Store



Вокруг нас достаточно разработчиков, которые хотели бы заняться своим проектом. Зачастую эти идеи так и пылятся в головах людей по самым различным причинам. Истории Вадима Смирнова из 2ГИС — как раз о том, как претворить их в жизнь. Потратив несколько выходных за год, он смог сделать пять разных проектов, не заработал миллионы, но при этом не разочаровался и не прекращает работать над pet-project'ами.

В основе публикации — доклад Вадима на AppConf 2017.
Читать дальше →

[recovery mode] Истории IT юриста. Жизнь аутсорсинг бизнеса. Часть 1



#ОТ АВТОРА
За свою карьеру я встречал много IT предпринимателей, помогал строить бизнес, решал проблемы. Видел взлеты и падения, успех и крах.

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

Для подтверждения своего опыта и компетенции, представлюсь. Меня зовут Вячеслав Устименко, я юрист и основатель компании LAWBOOT Lawyers & Consultants, блогер на YouTube канале Нерезиновая Долина.
Читать дальше →

Гибкий суррогат

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

Сегодня посмотрим на не так сильно распространенный, но более близкий к нам, программистам и разным ИТшникам, пример.

Конкретно вам НЕ стоит читать дальше, если вы МОЖЕТЕ в течение 5 минут ответить на вопрос: насколько изменилась скорость, или эффективность вашей работы за последние полгода?

Если вы ответили на этот вопрос цифрой, и цифра эта не равна нулю, то публикация не для вас.

Для 1Сников вместо нуля может быть Неопределено, для js'ников — undefined. Читать дальше →

Почему я не веду разработку ПО в Trello?

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

[Перевод] Как построить сообщество. Перевод книги «Социальная архитектура»: Глава 1. Инструментарий

image
Мой инструментарий Социального Архитектора состоит из 20 инструментов, каждый из которых соответствует какому-либо аспекту сообщества или группы. Их можно использовать двумя способами. Во-первых, с их помощью вы можете делать измерения существующего сообщества, оценивая его по шкале от нуля и выше. Во-вторых, вы можете использовать их для создания сообщества, при этом прилагая усилия там, где они наиболее необходимы.
  • Четкая миссия — заявленная причина существования группы.
  • Свободное участие — насколько легко люди могут присоединиться к группе.
  • Прозрачность — насколько открыто и публично принимаются решения.
  • Бесплатные участники — как много можно платить людям за участие.
  • Свобода работы с материалами (ремиксабельность) — насколько свободно участники могут использовать работу друг друга.
  • Четкость протокола — насколько хорошо прописаны правила.
  • Компетентность власти — насколько хорошо следят за соблюдением правил.
  • Нон-трайбализм — насколько далеко распространяются права группы над своими участниками.
  • Самоорганизация — насколько свободно могут участники определять свои задачи.
  • Толерантность — как группа разбирается с конфликтами.
  • Измеримый успех...Далее...


Последние посты