Рубрика «управление проектами» - 28

Есть на свете странные люди. Программисты, за которыми не надо проверять ни работоспособность решения, ни качество кода. Руководители проектов, которых не надо контролировать. Тимлиды, которые никогда не говорят «ну, не шмогла я…».

У них тоже случаются провалы, но рука не поднимается, голос не повышается их критиковать или песочить. Ты как будто понимаешь – этот человек точно сделал всё, что было в его силах.

Они редко просят помощи. Бывает, что ресурсы запрашивают, необходимые для выполнения работы. Но отказ в помощи их не расстраивает, а, кажется, наоборот – радует и бодрит. Как вызов – решить задачу в ограниченных ресурсах.

Вы таких людей наверняка видели. Возможно, в зеркале. Я долго думал, в чём причина подобного поведения. Особенно смущает тот факт, что они не всегда были такими – что-то, когда-то, с ними произошло, превратив их из «сделаю, если смогу» в «сделаю всё, что смогу».

Прошерстив всех знакомых за 15 лет, которые подходят под приведенное описание, в т.ч. самого себя, я пришел к выводу: причина в том, что эти люди когда-то оставались в одиночестве. Только его формы были разными.Читать полностью »

image

Привет, я Евгений Бойченко – сооснователь студии, которая разрабатывает мобильные приложения. За 10 лет работы вопрос «Почему так дорого?» я слышу чуть ли не ежедневно. Для многих клиентов мы искали возможности безболезненно снизить цену разработки, и в итоге у меня накопилось некоторое количество кейсов, которые решают проблему высокой стоимости мобильного приложения. В этом треде я призываю комьюнити делиться знаниями о том, как удешевить разработку мобильного софта без потерь. Начну с себя и своих секретиков, а вы присоединяйтесь в комментариях – вместе создадим гайд по экономичной разработке, который будет полезен обществу.
Читать полностью »

Думаю, мало кто стал бы спорить, что передовые проекты индустрии разработки программного обеспечения, IT отделы корпораций, в своей работе используют инкрементально-итерационные подходы. Со временем, Agile оброс горой идеализма и шарлатанства: коучи, менторы, мотиваторы — случайные люди, рассказывают о том, как нужно поверить в схемки и диаграмки, чтобы проникнутся общей целью.

Agile без идеализма. Когда и как именно работает гибкий менеджмент. Политэкономический памфлет - 1

Цель данной статьи — поставить идеалистичное отношение к Agile с ног на голову — материалистически объяснить, когда Agile работает, как именно работают те или иные ценности и принципы; какой Agile идеалистический, а какой материалистический.

Читать полностью »

Работа инженера — сплошное разочарование. Возможно, потому что у нас нет власти, а менеджеры сбрасывают на инженеров все проблемы и ожидают, что они будут решены к вчерашнему дню.

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

Вот общий сценарий, который разыгрывается между инженером и его боссом, инженером-менеджером. Менеджер спрашивает, сколько времени займёт выполнение новой задачи. Бывает, что инженер не делал эту задачу раньше, поэтому честно отвечает, что понятия не имеет. Менеджер не принимает такой ответ — и снова спрашивает. Тогда инженер даёт оценку практически наугад, а босс отвечает: «Это слишком долго». Даже если инженер знает, сколько времени займёт выполнение задачи и даёт реалистичную оценку, менеджер часто отвечает: «Это слишком долго. У тебя есть время до пятницы». Когда инженер спрашивает, как давно стало известно об этой задаче, босс отвечает, что месяц назад. Когда инженер спрашивает, почему он не сказал ему об этом месяц назад, тот просто смотрит на инженера, как будто не понимает вопроса.
Читать полностью »

Как я собирал статистику по брутфорсу наших серверов и лечил их - 1


Мы разместили 5 ханипотов, в дальнейшем просто «серверов», чтобы собрать статистику по брутфорсу RDP в наших сетях.

Один сервер находился в Лондоне, другой в Цюрихе, один в защищенной сети в M9, два других в дата-центре Rucloud в защищенной и незащищенной сетях. IP адреса каждого из серверов находятся в разных подсетях, каждый IP адрес отличается первым октетом. Если попытаться измерить «расстояние» скана между IP адресами по формуле:

((Первый октет подсети №1) – (Первый октет подсети №2)) * (2^24),

Если сканировать 0.0.0.0/0, атакующему придется пролистать как минимум 771751936 IP адресов, чтобы найти два самых «ближайших» друг к другу сервера. Вдобавок, каждый из серверов не отвечал на ICMP и каждый IP адрес не использовался никем в течение 3 месяцев, все 5 серверов открыли порты в одно и то же время. Все серверы были подключены к AD.
Читать полностью »

Организация работы в креативной команде: опыт Wrike, Miro, Revolut - 1

Мы в Wrike решили сделать встречу для сотрудников креативных команд – дизайнеров, маркетологов, проджект-менеджеров – чтобы поговорить об эффективных процессах там, где рутина может убить творчество. Позвали дизайн-лидов из Revolut, Miro и Wrike, чтобы они поделились своим опытом, наработками и секретами.
24 сентября, в 18:00 по Москве. Онлайн.
Читать полностью »

Об устаревании кода и жизненном цикле ПО - 1

Стартап, новые технологии, современные языки и фреймворки. Всё это так волнительно, когда мы начинаем делать что-то с нуля. И обязательно стараемся выбрать современные, популярные, любимые миллионами технологии для нашего проекта. Но время не останавливает свой неумолимый бег, и вдруг мы оглядываемся назад и видим, что нашему «стартапу» уже 15 с лишних лет. И мир вокруг давно изменился. А у нас в проекте всё тот же Basic/Delphi/Fortran/whatever. И как с этим жить?
Читать полностью »

Как некорректное делегирование отравляет IT-индустрию - 1

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

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

Наблюдая за работой десятков разных IT-компаний из разных сегментов я с уверенностью заявляю: так называемое «делегирование полномочий» в 90% случаев — фикция и способ самоутверждения менеджера. Потому что делегирование, это двунаправленный процесс, в котором должен быть не только сильный исполнитель (что очевидно), но и умный, со стальными нервами руководитель. И сейчас объясню, почему.
Читать полностью »

Привет! Представляю вашему вниманию перевод статьи «User stories are not requirements» автора Пер Лундхольм (Per Lundholm).

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

Читать полностью »

Jekyll на VPS за 30 рублей для состоятельных людей - 1


Статический HTML почти ушел в прошлое. Теперь сайты это связанные с базами данных приложения, которые динамически формируют ответ на пользовательские запросы. Однако, в этом есть и свои недостатки: более высокие требования к вычислительным ресурсам и многочисленные уязвимости в CMS. Сегодня мы расскажем о том, как поднять свой простенький блог на Jekyll — генераторе статических сайтов, контент которых берется прямиком из GitHub.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js