​​—-  Рекламный пост —- Пост проплачен  —-

В честь дня сисадмина скидка 26% на все курсы Слёрма по DevOps/Kubernetes/Ceph/Docker/Ansible.

Только до 28 июля. Промокод TEHDIR

Регистрируйтесь по ссылке http://bit.ly/2y68aye

​​Новости про большие компании

Снова про области ближайшего развития

Бывет, поручаешь сотруднику что-то и точно уверен в том, что он выполнит всё чётко.

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

Что это за области ближайшего развития? Это то, на что сотрудник в ближайшее время может стать способен.

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

Проблема в том, что поощрять и наказывать получится дорого. Прежде чем накосячить, сотрудник сначала демонстрирует готовность к этому "накосячить". Шутит про это, в обсуждениях проговаривает вариант "а что, если не получится?" под видом обсуждаемых рисков, сам выглядит как тот, кто может накосячить.

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

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

Следить за мелкими изменениями в области ближайшего развития дешевле. Это подобно вазе, которую дети столкнули со шкафа и она разбилась. Наказать детей можно, но вазу уже обратно не слепишь.

Чтобы лучше понять, что такое область ближайшего развития сотрудника, попробуйте любому из ваших коллег задать вопрос: "В чем состоит основная потенциальная возможность руководителя/команды/компании, которую мы, по твоему мнению, упускаем?"

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

Сортировка

Заспорили тут с коллегами на тему задачек на собеседовании - бесполезные и никому ненужные задачки о сортировке пузырьком.

Всплыла старая задачка: написать программку, которая получает на вход несортированный массив целых чисел от 1 до 100, сортирует его и печатает отсортированный массив, потратив на это не более 2х проходов.

Некоторые числа в исходном неотсортированном массиве отсутствуют, а некоторые повторяются более одного раза. Длина этого массива = K >= 100.

Доля

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

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

Доля в проекте - это как настоящая Любовь (все о ней говорят, но ни кто её не видел).

Ну а что делать, если предлагают Долю и сулят там далеко на горизонте золотые горы, когда добежите до продаж: "Эй, птичка! Летим на юг! Там много вкусного!" (с)

Каждому придётся решать самому, верить этому или нет, но если согласитесь, тон сменится немедленно на другой: "Пошёл, страус! пошёл!" (с)

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

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

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

Почему? Потому что делёжка в момент, когда всё ясно, будет происходит в той пропорции, в которой есть силы защищать свои права у всех сторон. Если попёрли продажи, то сильнее будут продаваны, а не разработчики. Это абсолютно неважно, что разработчик пёр всё на себе несколько лет, пока ни кто не верил в его продукт. Вообще. Все забудут об этом мгновенно, как только попрут первые клиенты на десятки и сотни миллионов.

Поэтому договариваться надо на берегу, когда ещё вообще ничего не ясно, прикладывая к этому максимум усилий и не стесняясь.

До тех пор, пока юридически железобетонно не прописаны все права, пользуйтесь еврейским принципом: берите деньгами!

Удачи!

П.С. Крылья? Ноги? Главное, - хвост!!! (с)

Форма регистрации для тех, кто хочет подрабатывать: https://forms.gle/1u6mecv7wzzzeZ5r9

Тестовое задание для бекенд-разработчиков питонистов:
===

 Необходимо реализовать библиотеку-клиент к Memcached. Библиотека должна на низком уровне реализовывать команды get/set/delete. 
При реализации необходимо использовать подход Test Driven Development.

Чтобы понять, как работает клиент, можно сделать вот такую telnet сессию, - она проиллюстрирует типичное общение клиента с сервером::

$ telnet localhost 11211

get key
END
set key 0 3600 3
xyz
STORED
get key
VALUE key 0 3
xyz
END

Для автоматизации проверок нужно прикрутить CI и проверку кода на соотвествие стандартам pep-8.

Также тебе пригодится документация: https://github.com/memcached/memcached/blob/master/doc/protocol.txt
===

Результат размести на github/bitbucket и пришли ссылочку!

​​Первый отзыв о тестовом

Дима Белявский пишет про работу программиста

В глазах окружающих:
10% - обдумывание идеи
40% - ее реализация
50% - пьет кофе и купается в деньгах

На самом деле:
10% - обдумывание идеи
40% - ее реализация
50% - поиск маленькой ошибки, из-за которой ни хрена не работает

​​Сходил в пич-клуб стартапный, послушал, как люди оценивают стартапчики! Очень познавательно.

Главная мысль: Тебе рассказывают, почему у Тебя ничего не получится!

Евгений Абраменко набрасывает на вентилятор

БДСМ в айти или кто-то должен пострадать

Понял, что реальные примеры находят более живой отклик у аудитории. Что ж, продолжим эту добрую традицию.

Реальная компания. Группа стартапов. Матричная структура. То есть когда у одного специалиста есть функциональный и проектный руководитель. А то и несколько проектных руководителей. Я укажу несколько признаков, а вы скажите, знакомо или нет

1. Разработка не берет задачи от бизнеса пока не будут выполнены все их требования по постановке. В том числе они могут завернуть задачу потому что она им просто не нравится, они не считают нужным ее делать. Без объяснения причин. У проектного менеджера нет власти приказать им делать эти задачи и делать их именно так как он прописал. При этом за реализацию и сроки - ответственнен он

2. Проектов больше чем ресурсов раза в 3-4. При этом в единицу времени приоритет отдается одному из трех. Начинается драка за ресурсы. При этом проектный менеджер потом не может сказать, что проект не сделали, потому что не дали ресурсов. Мол, плохо дрался. Все бы ничего, но в таком раскладе кто-то да пострадает. То есть 3 из 4 проектов страдают. Зачем было создавать столько проектов, если знаешь, что вести будешь только один?

3. Все командуют всеми и никто никем. Реальная власть только у одного человека - и это владелец компании. Делегирование полномочий отсутствует как класс. При этом везде есть крайние: тимлиды, проектные менеджеры, продакты. Короче, крайние

4. Топ менеджменту на все насрать. "Мы хотим, чтобы мышки стали ежиками, а как - это ваши проблемы". При этом исполнители всегда съезжают, мол - не их. Таким образом проектные менеджеры, тим лиды и продакты опять кто? Верно. Крайние

5. HR делают вид, что все "круто и классно", раскачивают HR бренд, вешают лапшу на уши приходящим специалистам, что у них тут рай. По факту, те же яйца, как и везде.

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

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

И если сбоит хотя бы одна часть из трех, то прибыли ждать не придется.

Друзья мои, сталкивались с подобным?

Если у вас девушка владелец продукта, то правильно говорить - владычица, а не продакт оунерка!

#деньтехдира скоро!

Коллеги!

Я открываю техдирский клуб в виде строго закрытого чатика.

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

Заявки слать сюда: https://docs.google.com/forms/d/1gdBF6I34SnAxPELNS94YvH6cg6G1m23WFZxmXRgqT9o/edit

Отношения бизнеса и CTO: любовь, трагедия, разочарование

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

Техдир видит в бизнесе фантазёров и ветреных людей: сегодня говорят бежать в одну сторону, завтра в другую, а послезавтра обратно! При том виноват всегда получается именно он.

Как подружить эти два начала? Как придать структуру хаотичным метаниями бизнеса? Как объяснить бизнесу, что разработчики будут месяц пахать исключительно ради избавления от техдолга? Как выстроить процессы, чтобы можно было гарантировать бизнесу чёткие сроки?

Никто не знает, чем именно должен заниматься СТО, а чем не должен! Никто не знает, как стать техдиром! Никто не знает, как проверить, техдир — настоящий или только притворяется!

И как с этим бороться? Сейчас в основном ставят эксперименты на компетентность и совместимость, цена которых исчисляется миллионами. Хорошо, если рублей!

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

День Техдира в Санкт-Петербурге 3 сентября:  оффлайн встреча профессиональных техдиров, руководителей разработки, девопс, тестирования и тимлидов.

CEO, продакты и тимлиды, общающиеся с технарями, - мы ждём вас!

Посещение бесплатное, но надо предварительно зарегистрироваться (чтобы на всех пива взяли 🍻):  https://cto-day.ru/

Лайк & repost, если хотите, но не можете:
https://www.facebook.com/ctorecords/posts/10156134640242504

Суперпростое тестовое задание для питонистов
(используется для отсева на уровне hr)

Нужно написать python скрипт, который запускается из командной строки, на вход принимает неформатированный текстовой файл, наполненный текстовыми строчками неограниченной длины. Каждая строчка – это один абзац. Задача скрипта:

1. Удалить повторяющиеся пробелы в строках и дублирующиеся переводы строк;
2. Напечатать выравненный по ширине текст шириной 80 символов (за счёт добавления пробелов между словами);
3. Отделять каждый абзац пустой строкой, используя только стандартные библиотеки кроме python кроме textwrap; format нельзя использовать;
4. Начало каждого абзаца должно начинаться с красной строки в четыре пробела;
5. При этом разбивать слова по слогам не требуется, а если получившаяся строка является окончанием абзаца, то её надо выравнивать по левому краю;
6. Слова длиной более 80 символов укорачивать до 79 символов, добавляя в их конце символ многоточия.
7. Важно, чтобы в конце любых строк кроме последней строки абзаца не оставалось "висячих" предлогов и союзов: и, или и других;
8. Если непоследняя строка абзаца состоит менее, чем из трёх слов, занявших менее 70 символов, её необходимо выровнять по левому краю (не расширять пробелами расстояние между словами)

Результат выложить на гитхаб.

Сложное тестовое задание для питонистов

Нужно написать python скрипт, который запускается из командной строки, на вход принимает текстовые предложения вида:

1. В следующем году 1 февраля в полночь
2. Через два недели в понедельник в 14:00
3. Каждый год во второй понедельник сентября
4. ...

На выходе скрипт должен выдать точную дату время описанную в тексте.

1. Если в тексте написано циклически повторяющееся события, нужно выдать три первые дата с указанием временем.
2. Если из описания неясно, какое время, то использовать 00:00.
3. Нельзя использовать для решения задачи любые api. Скрипт должен работать на локальном ноутбуке без интернета.

П.С. Задача имеет решение, так как на деле каждый может написать в воцаппе "встретимся завтра в 14:00" и точное время задетектится с предложением добавить его в календарь.