18 марта 2019

Юваль Ной Харари. Sapiens. Краткая история человечества.



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

Эта книга встала в список после того как заметил в своей ленте на фейсбуке цитаты из нее от Леши Лупана (могу путать, но да не суть).

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

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

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

Оценка : 8/10


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

14 февраля 2019

Software Engineering at Google by Fergus Henderson


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



Software development

The Source Repository

Write access to the repository is controlled: only the listed owners of each subtree of the repository can approve changes to that subtree.

Очень интересно кто и когда определяет кто является владельцем той или иной части дерева?  почему этот человек на протяжении долгого времени является компетентным в этой  части дерева?
Как происходит процесс изменения владельца?

Each subtree is required to have at least two owners, although typically there are more, especially in geographically distributed teams.

Most larger teams also have a “build cop” who is responsible for ensuring that the tests continue to pass at head, by working with the authors of the offending changes to quickly fix any problems or to roll back the offending change.

Интересная роль, наводит на мысли о  flaky tests и всем таком нехорошем, но вполне реалистичном.

The Build System

The build system’s implementation uses Google’s distributed computing infrastructure.

Enforcing that all dependencies be correctly declared is a consequence of distributing the build: only the declared inputs are sent to the machine on which the build step is run.

The build system tracks dependencies on changes to the build rules themselves, and knows to rebuild targets if the action to produce them changed, even if the inputs to that action didn’t, for example when only the compiler options changed.

The build system stays resident in memory so that for rebuilds it can incrementally analyze just the
files that have changed since the last build.
The tests can be either synchronous, i.e. run before sending the change for review and/or before committing the change to the repository (good for fast-running tests); or asynchronous, with the results emailed to the review discussion thread.

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

Code Review

Google has tools for automatically suggesting reviewer(s) for a given change, by looking at the ownership and authorship of the code being modified,  the history of recent reviewers, and the number of pending code reviews for each potential reviewer.
сам давно  думаю про назначение ревьюрам авторов изначального кода, но есть ряд вопросов к правильности реализации. Балансировку код-ревью по загруженности ревьюеров уже давно у себя сделали, работает.

In addition to the main section of the repository, there is an “experimental” section of the repository where the normal code review requirements are not enforced.
Людям надо давать место для песочницы, иначе они сами себе его сделают, но уже на гитхабе.

One way in which keeping changes small is encouraged1 is that the code review tools label each code review with a description of the size of the change, with changes of 30-99 lines added/deleted/removed being labelled “medium-size” and with changes of above 300 lines being labelled with increasingly disparaging labels, e.g. “large” (300-999), “freakin huge” (1000-1999), etc.

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

Programming languages

Commonality of process is a key to making development easy even with an enormous code base and a diversity of languages: there is a single set of commands to perform all the usual software engineering tasks (such as check out, edit, build, test, review, commit, file bug report, etc.) and the same commands can be used no matter what project or language. Developers don’t need to learn a new development process just because the code that they are editing happens to be part of a different project or written in a different language.

Вот эта кроссязыковая унификация - это прям очень недемократично, но уже даже в масштабе средней конторы очень нужно. Потому что в таком зоопарке (officially-approved programming languages at Google: C++, Java, Python, Go, or JavaScript) должны быть общие правила для всех животных.

Launch approval

The launch of any user-visible change or significant design change requires approvals from a number of people outside of the core engineering team that implements the change. In particular approvals (often subject to detailed review) are required to ensure that code complies with legal requirements, privacy requirements, security requirements, reliability requirements (e.g. having appropriate automatic monitoring to detect server outages and automatically notify the appropriate engineers), business requirements, and so forth.
Особенно актуально в контексте всяких GDPR, пакетов Яровой, масштабных сливов пользовательских баз и прочего.
Ну и да - культурой стартапа тут уже не пахнет :).

Post-mortems

Whenever there is a significant outage of any of our production systems, or similar mishap, the people involved are required to write a post-mortem document.
The impact section tries to quantify the effect of the incident, in terms of duration of outage, number of lost queries (or failed RPCs, etc.), and revenue.
Периодически проводя разборы полетов убеждаюсь, что вместо встречи можно сделать шаблонный документ, с довольно строгими критериями его ревью (может быть даже отдельно на эту тему напишу).

Frequent rewrites

Most software at Google gets rewritten every few years.
This may seem incredibly costly. Indeed, it does consume a large fraction of Google’s resources. However, it also has some crucial benefits that are key to Google’s agility and long-term success. In a period of a few years, it is typical for the requirements for a product to change significantly, as the software environment and other technology around it change, and as changes in technology or in the marketplace affect user needs, desires, and expectations. Software that is a few years old was designed around an older set of requirements and is typically not designed in a way that is optimal for current requirements. Furthermore, it has typically accumulated a lot of complexity. Rewriting code cuts away all the unnecessary accumulated complexity that was addressing requirements which are no longer so important. In addition, rewriting code is a way of transferring knowledge and a sense of ownership to newer team members. This sense of ownership is crucial for productivity: engineers naturally put more effort into developing features and fixing problems in code that they feel is “theirs”. Frequent rewrites also encourage mobility of engineers between different projects which helps to encouragecross-pollinationofideas. Frequentrewritesalsohelptoensurethatcodeiswritten using modern technology and methodology.

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

Frequent rewrites also help to ensure that code is written using modern technology and methodology.
Лучше постоянно переписывать софт, чем написать его один раз на коболе, а спустя 30 лет заниматься полным перепроектированием в купе с реверс-инжинирингом для того чтобы избавится от нподдерживаемого никем легаси. Но даже для этого нужно найти и вывести из криосна кобол-программиста, что сука дорого!


This sense of ownership is crucial for productivity: engineers naturally put more effort into developing features and fixing problems in code that they feel is “theirs”.
Суровая правда о том, почему почти никто не любит фиксить баги в чужом коде.

Project management

20% time

Secondly, it provides management with visibility into activity that might otherwise be hidden. In other companies that don’t have an official policy of allowing 20% time, engineers sometimes work on “skunkwork” projects without informing management. It’s much better if engineers can be open about such projects, describing their work on such projects in their regular status updates, even in cases where their management may not agree on the value of the project.
Лучше мы расскажем, чем во дворе объяснят (с) старый анекдот.
Вам что больше нравится - когда разрабы сидя в офисе в youtube пырятся или хотя бы иллюзорный шанс того что они хоть что-то полезное напишут?

Objectives and Key Results (OKRs)

OKRs provide a key mechanism for communicating what each part of the company is working on, and for encouraging good performance from employees via social incentives... engineers know that their team will have a meeting where the OKRs will be scored, and have a natural drive to try to score well, even though OKRs have no direct impact on performance appraisals orcompensation. Defining key results that are objective and measurable helps ensure that this human drive to perform well is channelled to doing things that have real concrete measurable impact on progress towards shared objectives.

Самое главное - это не для того чтобы оценить насколько вам поднять зарплату или кого уволить. Это чтобы понимать куда вся эта херня движется. Когда у вас хотя бы 100 разрабов в 10-ке команд - это уже нихера не так очевидно.

Project approval

Although there is a well-defined process for launch approvals, Google does not have a well-defined process for project approval or cancellation. Despite having been at Google for over 10 years, and now having become a manager myself, I still don’t fully understand how such decisions are made.
Опаньки ! Даже в гугле проекты непонятно откуда берутся. 🙂
Я кстати общаясь с коллегами много где такую фигню наблюдаю.
Кто-то что-то напрототипировал, где-то в курилке посовещались, поймали тех.дира за жопу, и проект стартовал. Хорошо если в трекере хотя бы остаются какие-то артефакты начала проекта. Чаще всего их нет, а именно в начале проекта принимаются все самые критически важные и дорого стоящие потом решения.
Резюмирую :  природа зарождения проектов в современных организациях редко бывает ясной и понятной.


Corporate reorganizations

In a large, technology-driven organization, somewhat frequent reorganization may be necessary to avoid organizational inefficiencies as the technology and requirements change.
Осталось придумать как это делать без визгов со стороны чилавекаф.
Facilities
Employees are assigned an individual seat, but seats are re-assigned fairly frequently (e.g. every 6-12 months, often as a consequence of the organization expanding), with seating chosen by managers to facilitate and encourage communication, which is always easier between adjacent or nearly adjacent individuals.
Прям игра в классного руководителя и рассадку учеников по классу.

Training

In addition, each Noogler is usually appointed an official “Mentor” and a separate “Buddy” to help get them up to speed.
Давно думаю что действительно одного человека на задаче мало. Всегда нужен "контрольный тролль", который вовремя встролльнет исполнителя.

Performance appraisal and rewards

Feedback is strongly encouraged at Google. Engineers can give each other explicit positive feedback via “peer bonuses” and “kudos”.
Очень хочется попробовать такую схему, особенно в части с анонимным распределением по команде пусть и скромного бонуса. То есть дать всем и каждом возможность распределить бонусный фонд и дальше посмотреть  на то , кто больше денег получит.

Google has a very careful and detailed promotion process, which involves nomination by self or manager, self-review, peer reviews, manager appraisals; the actual decisions are then made by promotion committees based on that input, and the results can be subject to further review by promotion appeals committees. Ensuring that the right people get promoted is critical to maintaining the right incentives for employees.
Без комментариев. Хотелось бы больше деталей.

Manager performance is assessed with feedback surveys; every employee is asked to fill in an survey about the performance of their manager twice a year, and the results are anonymized and aggregated and then made available to managers. This kind of upward feedback is very important for maintaining and improving the quality of management throughout the organization.

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



P.S. в разделе про тестирование ну ничего интересного не написано. 

06 февраля 2019

Почему не нужно боятся CFP

Часто задают вопрос «А много ли докладов Программный Комитет отфильтровывает на Гейзенбаге?» 
Этот вопрос наводит меня на мысли о том, что в голове у людей есть довольно искаженное понимание того, чем на самом деле занимается ПК конференции.



Ну, по порядку:
  1. ПК конференции действительно фильтрует заявки на доклады, которые прилетают через  Call For Paper форму. 
    Второй гранью этой правды является то, что фильтрация - это к сожалению даже не 5% работы, а  еще меньше.
    Полностью нерелевантный доклад виден по описанию и тезисам. Слаборелевантный уже так просто не обнаружить - нужно созваниваться с докладчиком, а это уже явно не 1 клик мышкой, а согласование времени созвона со спикером, собственно сам звонок минут на 15-30 и оформление каких-то заметок после. 
  2. Только фильтровать - довольно деструктивный подход, поэтому ПК занимается активным поиском и приглашением (сорсингом)  интересных докладчиков. Как вы думаете с какой попытки люди из Facebook стали отвечать на наши письма ? (Спойлер : с четвертой). Но даже сорсингом заниматься нужно осознанно и для этого приходится анализировать формы обратной связи (ФОС, дада, те самые на 90+ вопросов, которые мы слезно просим заполнить). Оттуда мы узнаем какие темы и группы тем вызывают интерес  у аудитории, что мы упустили и что нужно искать в будущем. 
  3. Задачей ПК конференции является помощь докладчику в том какие аспекты в его докладе можно и нужно осветить больше, а какие - меньше, чтобы сделать доклад интересным для публики.
    Мы помогаем сделать доклад, но оригинальная идея - всегда за спикером. Мы ее не трансформируем и не меняем. И из этого вытекает следующий пункт.
  4. Разница между опытным и неопытными докладчиками. Неопытный приходит с одной темой и ПК зачастую приходится долго выведывать интересные нюансы, которые сам спикер считает фигней. Опытный - приносит целую пачку точек зрения на проблему(-ы) и предлагает ПК сказать про что будет интересно рассказать. На работу с каждым типом спикеров уходит масса времени, но работа в каждом случае -  разная. Более того бывает так , что ПК видит что у спикера есть очень интересная тема, но которую он не успеет проработать, поэтому мы переносим человека на следующую конференцию - с весны, на осень; с осени - на весну. Разбрасываться интересными темами никто не будет. 
  5. Информационная ассиметрия. К счастью в последнее время спикеры приходящие в CFP все чаще задают вопрос «А будет ли интересным доклад про ХХХХ?» и это радует. Почему радует ? 
    Потому что никто кроме ПК конференции не знает текущего положения дел в пуле докладов, их степени готовности, расстановки по темам. Имея на сетку в 30 докладов, два про статический анализ кода, шансы попасть в нее третьему - закономерно ниже. Исключения конечно бывают, но мы стараемся балансировать программу (у нас даже софтина специальная поверх OptaPlanner написана).
  6. Запас. Одним из самых неприятных  моментов, который случается в процессе подготовки конференции является выпадение спикера из пула , по разного рода причинам. И эту дыру нужно как-то закрывать. Круглые столы и lightning talk-и конечно работают, но полноценный спикер работает лучше. Запас надо искать и держать с самого начала, потому что до начала конференции ты не знаешь - пригодится он или нет.
  7. Информационное освещение конференции - интервью со спикерами, общение в telegram-чатике с участниками, решение каких-то организационных  вопросов.
  8. Еще куча всяких мелочей... 


Call For Paper форма (a.k.a Подача докладов) на весенний Гейзенбаг, который будет в Питере, у нас уже открыта. 



P.S. еще одна суровая правда из работы ПК Heisenbug - CFP форма не закрывается 🙂 . Никогда!  

13 ноября 2018

Heisenbug: Зачем я этим занимаюсь вообще?

People always asking me if I know Tyler Durden...


Люди часто задают мне вопрос - зачем я занимаюсь Гейзенбагом и сколько мне за это платят?
Отвечать каждому вопрошающему лично надоело, поэтому (несмотря на то что блог осознанно забросил) решил написать.

1. Мне никто ничего не платит.
Да, вот такой вот шок-контент.
6-7 декабря будет 5 (пятый!) Гейзенбаг и ни за один из пяти, ни за все сразу я не получил ни копейки денег.

После этого моего ответа на первый вопрос люди обычно задают второй - зачем я этим вообще занимаюсь? Отвечаю.

2. Начиная с 2010 года я побывал на многих конференциях. Началось все с Google Developer Day в Москве - хоть это и было мероприятие организованное компанией с целью рассказать (порекламировать) о своих продуктов, оно открыло мне глаза на то что может быть вообще.
Со временем я стал привередливее, и в 2014 году, скатавшись на конференции в США и Европу понял что я не вижу перед собой ни одной открытой конференции посвященной тестированию на которую было бы непротивно сходить/съездить.

Исключением, пожалуй, являлся GTAC , но его уже пару лет как нет в природе, сейчас на его место встал @scaleconference, но меня раздражает идея закрытой конференции для представителей 5-10 компаний в США, доклады с которой все равно есть в открытом доступе.

Почему противно ?
Потому что я искренне верю что тестирование - это инженерная дисциплина, и исходя из этого я не хочу видеть на конференции доклады о том как правильно наматывать сопли на кулак в SCRUM-команде тестировщику или надо ли их размазывать по kanban-доске.


Спасибо моим друзьям из JUGru Group, которые предложили сделать эту конференцию.


Доволен ли я Гейзенбагом ? Скорее да, чем нет.
Но я точно знаю, что еще в нем можно сделать лучше.

Приходите, будет интересно!
P.S. промокод DiscountByPapaMinos еще работает :)


18 сентября 2018

День нетестировщика и скидочки на зимний Heisenbug

Давеча тут был День Тестировщика,
 но я был в Праге и был занят, 
поэтому руки дошли только теперь. 
Вспомнилось мне тут как я попал в тестирование. 
При том слово «попал» - оно ключевое. 

Мне позвонил Слава Ванюлин, тогда еще менеджер проекта, а ныне руководитель всея Ауриги, и предложил поучаствовать в проекте.
В этот момент я сидел на "лавке запасных" как часто бывает в компаниях-аутсорсерах, когда один проект, в котором ты участвовал уже закончился, а в следующий тебя еще не пристроили. 
Проект был про встраиваемое ПО и мне было интересно. 
Команду тестирования на проект собирали с нуля хотя проект уже был полгода, нас было 3-е и тест-менеджер. 

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

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

К вечеру я все-таки осилил провести дымовой тест до конца, хотя начинать с самого начала приходилось раз… хер его знает сколько раз пришлось сделать это в тот день. Много.

К тому моменту я бросил курить. 
Но выйдя вечером из офиса сразу купил себе пачку сигарет и немедленно закурил. 
Дымовой тест заставил дымить меня, и это я сейчас не только про сигареты
Я чувствовал себя полным лузером - провести один приемочный тест за целый день. 

Дальше началась работа.
Мы втроем херачили автотесты на Jython-е как проклятные - по 20-25 автотестов в день - основной интерфейс у продукта был ssh+консоль. 
Дымовое тестирование со временем превратилось в рутину, документацию и тест-план я, конечно, вылизал - я своей шкурой прочувствовал почему она нужна актуальная. 
Спустя 4 месяца меня забросили разработчиком на другой проект. 

К чему я это все ? 
Этот первый день меня научил очень многому. 
Я мог бы сесть и сказать, что документация не актуальная , и доступов нет и т.д. но это никак  бы не помогло тушить и без того горящий проект. 
Вместо этого (честно , сам не знаю почему) я пошел и стал долбить и без того занятых разработчиков чтобы хоть как-то дойти до поставленной передо мной цели. 
Я почему-то не сдался и не спасовал перед системами, с которыми я тогда не был знаком, совсем.
Я увидел что тестирование - это сложно. 
Даже когда вы все сидите в 3-х комнатах на одном этаже и ты к каждому можешь подойти - это все равно сложно.
Я увидел, что тестирование - это не только и не столько обезьяний труд с тест-планом в одной руке и мышкой в другой. И такое (обезьянье) тестирование я тоже потом увидел, но я уже знал, что есть другой мир. 
И, наверное, именно тогда в мою голову залетела мысль о том, что тестировщик - это такая же инженерная профессия, как и разработчик.

Тот, кто дочитал до этого момента - молодец, и будет поощерен.
Вот вам скидочка на зимний HeisenbugDiscountByPapaMinos.

29 августа 2018

Мысли Мудрого Мавроди , часть 2 - Этика по@#$зма

Второй выпуск в этом формате.


Мной постоянно были недовольны в разных аспектах. Родители. учителя, руководители, женщины. В какой-то момент времени я понял что "недовольные мной" в моей жизни будут всегда. К этому нужно относится как к фону. И делать то, что хочется делать. Недовольные все равно будут. похуй-пляшем Пренебрегаем и вальсируем.

Новое можно продать. Просто потому что оно «новое». 
Не все правда понимают что «новое» можно продать несколько раз. При том в разных измерениях. Можно продать сначала в столице, потом в регионах, потом в других странах (ну, может быть). 
Можно продать в разных форматах. Личный автомобиль, такси, аренда автомобиля, каршеринг, подписка на автомобиль. 
А еще «новое" можно продать как «новое» дважды. Особенно если ты идешь по чьим-то стопам, огибая острые углы и не попадая в ямы, и не делаешь ошибок. Так работают многие. И им похуй, ведь работает.

Язык и менталитет на самом деле много очень много значат.
Именно поэтому существует десятки клонов LinkedIn-а, CraigsList.
Проблема на самом деле в том что нельзя вот просто так взять и перевести с языка X на язык Y. 
(Ну или можно, но в ограниченном числе случаев).
Есть еще какая-то «национальная составляющая» на которую всем непохуй, которая дает возможность жить проектам клонам.
  
Основой реально работающих процессов в больших организациях в том числе является похуизм. 
Похуизм и бюрократия.
"Пока вы не напишете мне эту бумажку как положено я не буду для вас ничего делать, мне похуй» - примерно так это выглядит.  Это заставляет каждого конкретного шустрика роптать, но в том числе и заставляет крутиться этим колесам для миллионов.

Есть примеры вакансий-могильников.
Выглядит это примерно как "водитель, с опытом вождения болида F1, плюсом будет умение вождения БТР, только  с личным автомобилем». 
Суть в том что внутри компании ввиду того, что Друкера нынче читать не модно, вырос незаменимый человек.
Потом этот человек куда-то ушел - похуй по каким причинам - перегорел, переманили, устал.
И теперь этого бывшего одного человека очень надо заменить. 
Поэтому за голову такого человека предлагают награду, особенно если он добровольно сдастся в руки рекрутера. 
И,да, всем похуй, что таких не существует.


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

Подумалось тут, что предприниматель - это человек с иллюзией максимально-точной картинки его будущего бизнеса. И имея эту картинку в голове он принимает решения, которые ведут его  в сторону этой картинки. 
Есть четкое видение конечного результата, необходимых для этого действий, и есть четкое понимание на что в этой все картине похуй не важно. 
Вот то, на что похуй - это можно купить, арендовать, fake it until you make it, и так далее со всеми остановками.
И еще одно интересное свойство у предпринимателей есть - это свойство искусственно абстрагироваться от того что похуй не представляет для него интерес вот конкретно сейчас. 

Когда ты инженер ты можешь сделать что-то конечное и завершенное, потому что ты создаешь вещи или программы. Ты можешь «закончить».
Менеджер «кончить» не может. Потому что все что он создает - команда.

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

28 апреля 2018

Про Heisenbug и скидочки на него

КДПВ

Решил тут чот порефлексировать на тему Гейзенбага.

Первый раз мы заговорили о конференции про тестирование с Лешей Федоровым летом 2014 года на кухне московского офиса Одноклассников.
А летом 2016 года Леша позвонил и сказал примерно следующее: "Мы тут решили попробовать сделать конференцию про тестирование. Нам нужно хотя бы три человека в программный коммитет ? Ты как, в деле ?"

Я сказал да, и вот на горизонте уже 4 (четвертый, блин!) Гейзенбаг.

Каждый Гейзенбаг отличается от предыдущего. Очень сильно.

На первый мы собирали программу практически по знакомым спикерам и работа ПК была больше ориентирована на сорсинг докладов, нежели на подготовку.
Сейчас CFP-форма начала работать на нас - то есть сейчас достаточно высокую долю спикеров мы получаем из заявок, которые сами спикеры и прислали, поэтому фокус сместился на подготовку докладов.

На самом деле это адовый труд раз в полгода выводить на сцену качественный контент в определенной тематике. Причин тому несколько.
1. Его столько нет. Ну реально, даже у разработчиков нет полностью свежей программной сетки из новых тем и докладов раз в полгода. (Мой коллега, Олег Анастасьев, говорит что только раз в два года на конференциях появляется что-то новое и стоящее внимания.) Исключением, пожалуй, может являться только JavaScript и мир фронтенда :).

2.  Спикеры. Не каждый хочет рассказывать, не каждый кто хочет - может, и уж точно не каждый, кто хочет и может - в силах довести это до конца. Нас (я имею ввиду ПК) часто критикуют за высокие требования к подготовке доклада. Мы к этой критике вдумчиво прислушиваемся. И, действительно, для того чтобы сделать хорошее выступление нужно обладать внутренней мотивацией.

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

Чем еще примечателен грядущий Гейзенбаг ?
Тематикой докладов.
Тестирование меняется и очень хочется рассказать устами спикеров об этом всем.
В этот раз у нас будет два доклада про краудсорсинг и его применение в тестировании (от Оли Мегорской из Яндекса и Насти Семенюк из ВКонтакте), доклад про Model-Based Testing на основе сетей Петри, и про тестирование компиляторов (для любителей хардкора :)). Это конечно не все достойные доклады, это мой личный шорт-лист :).

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

В прошлый раз мы делали "круглые столы" - зашло так себе.
Но мы продолжаем экспериментировать на эту тему и сейчас в программе две BOF-сессии.
(Просто потому что мы верим что такому количеству умных людей из отрасли есть чем поделится друг с другом, и это будет интересно и полезно.  Наша задача - найти правильный формат!).

Ладно, я тут еще долго могу графоманить.
Всем кто хочет поучаствовать в качестве слушателя и дочитал до этого места - промокод со скидкой PapaMinosPromo.

P.S. А те, кто не будет тормозить могут поиметь с этого промо-кода несколько больше потому что с 1 мая цена поднимется.





17 апреля 2018

Мысли Мудрого Мавроди - МММ


Накипело тут всяких  мыслей, попробую новый формат.


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


Мы не Гугл. Не нужно изобретать свой велосипед, давайте возьмем что-то с рынка, что поддерживаем не мы, внедрим у себя и будем заниматься действительно важными вопросами.
Классная модель мышления, иногда даже работает.
Вам не нужно оперировать в масштабах гугла для того, чтобы столкнутся с проблемами, присущими Гуглу.
Вам нужно лишь НЕ ОБЛАДАТЬ достаточным количеством ресурсов для решения той или иной проблемы и voi-la - вы уже находитесь в положении Гугла, когда нужно креативить чтобы решить проблему.



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


Увольнение/уход человека - это «землятресение» компаний. 
Невооруженным глазом их можно наблюдать,  когда кто-то уходит/кого-то уходят и люди начинают двигаться вверх, при том не один, а сразу цепочкой.
Для того чтобы видеть «землятрясения» и их последствия необходимо сидеть достаточно высоко и обладать достаточной временной перспективой наблюдений. 
Аналогия с землетрясениями хороша еще и тем что как и в природе предсказывать их пока не научились, и в любой конкретный момент времени конкретно непонятно  - оно будет одно или серия толчков ? 
Смотришь вот так вот со стороны за серией «толчков» - один поскандалил и ушел, второй перевелся в другой отдел/проект, третий просто ушел - и видишь как после  этого начинает буксовать проект или какой-то его кусок. 
Знание о форме тектонических плит, местах  их столкновений и хороший сейсмограф конечно могут позволить верхнему менеджменту снизить потери от землетрясения, но не сделать их нулевыми. В лучшем случае времени и ресурсов хватит на эвакуацию, хотя и это не мало. 


В жизни каждой организации неизбежно наступает период когда менеджеры в ней  превращаются в стратегов.
Менеджер становится стратегом не сразу, не в один день. 
Менеджер делает какое-то дело, его люди делают это дело. 
Дело даже получается, так может повторится даже несколько раз. 
Люди у менеджера учатся, проявляют инициативу.
И в какой-то момент менеджер понимает, что ему больше не нужно делать менеджерскую рутину.  Что он может подумать о ней… о стратегии.
Стратегия, сука, непонятная.
Она вроде бы и есть, а вроде бы и нет. Вот с тактикой все просто - взял кусок работы, нарезал на спринты, ходишь на стендапы, решаешь проблемы команды, получаешь результаты и обратную связь. 
А со стратегией все сложно - ты ее подумал, обсудил, проговорил с людьми. Может быть даже записал на бумажку и придал ей официальный статус.
Но ее нет. Физически ее нет. 
Поэтому стратегу нужно, конечно, подумать эту вот самую стратегию, обсудить ее, проговорить ее и ... идти выполнять. Самому.
И тут собственно и наступает тот самый критичный для менеджера момент - кто-то может ответрнуться (пусть и на время) от этой бездны стратегии, и пойти обратно в окопы, а кого-то засасывает эта метафизическая бездна. 
Это конечно идеализированная картина мира, где только черное и белое, но (!!!)- конченых стратегов нужно отстреливать! 



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


Организация внутри организации (внутренние организации) - это довольно распространенный паттерн, источник зарождения массы внутрикорпоративных войн (и сражения в них намного более кровавы, нежели ежедневные потасовки на конкурентном рынке), способ трансформации и расширения организаций. 
Проблема возникает тогда когда культура одной маленькой, но очень боевитой организации внутри начинает вступать в конфронтацию с культурой большой «материнской» организации. 
Менеджеры постигшие «дзен» умеют исскуственно создавать этот конфликт, управлять им и вовремя трансформировать организацию (и внутреннюю, и внешнюю).


Самыми большими организациями за всю историю человечества всегда были армии.
Ни государство, ни церковь, ни какая бы то ни было другая организация не может оперировать также, как армия. 
Вдумайтесь - по получению соответствующего сигнала откуда-то из штаба целая воинская часть (а это как бы тысячи человек) должна упаковаться, погрузится в технику, собрать все необходимые манатки типа еды, боеприпасов, горючего, встать на марш и двинуться в нужную сторону. Для бронетанковых частей в СССР норматив был 45 минут.
А теперь контрольный вопрос - вы эвакуацию обычного офисного здания по учебной пожарной тревоге когда-нибудь видели ?  Хорошо если за 45 минут все оккупированные клозеты освободятся. 
Если вы хотите что-то улучшить в своей организации - поищите схожий армейский опыт.
Да,опыт этот специфичен, но - его много, есть вариативность кейсов, проверка временем. 


Боеспособность армии определяется младшим ( те кто непосредственно могут опиздюлить за нечищенные сапоги и невыглаженную форму каждого солдата) и средним (те, кто обеспечивает своевременный подвоз еды и боеприпасов, эвакуацию и ремонт раненых) командным составом. 
Младший и средний командный состав - это фундамент, на котором стоит любая армия. 
Если этот фундамент хорош, то некоторые(!) ошибки верхнего управления могут(!!!) быть нивелированы на местах, и цели будут достигунты. 
Примерно то же самое и в мирных организациях. 
Здоровый нижний и средний менеджмент могут вывозить организацию в нормальных условиях очень долгое время. 
Существенной разницей же является то, что неправильные стратегические решения в  армии очень быстро выявляются в виде потерь.
В бизнесе - не все так просто и потери могут случится кумулятивно и потом. 



Организации масштабируются временем. Временем нанятых людей.
Проблема при этом заключается в том, что масштабирование системы управления этими людьми не так просто. Именно поэтому часто можно увидеть такую картинку когда в подразделении было 10 человек, куча работы которую надо сделать, полное понимание размеров этой кучи менеджментом и всеми участниками процесса, а потом стало 20, все заняты работой по самые гланды, но что сделано (доведено до конца, внедрено) - никто уже понять не может. 
Самым простым, очевидным и неправильным решением этой проблемы является кратное масштабирование аппарата управления («давайте на каждые 5 тестировщиков, у нас будет один ведущий, а на каждых двух ведущих - тест-менеджер»).



Есть моменты соприкосновения/столкновения умов. 
Они нужны любой организации, которая что-то делает умами людей.
Каждый такой момент состоит из нескольких компонентов. 
Первый - это состав. Он не случаен, он всегда строго ограничен, всегда присутствуют неслучайные люди, иногда (!!!! ИНОГДА !!!!) к ним можно кого-то добавить. Нельзя просто взять и вставить в этот процесс «чужого» человека. 

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

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

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

11 апреля 2018

Книга: Роберт Саттон : Не работайте с мудаками.

Собственно читал довольно долго.
Тема не раскрыта.
Почему книга удостоилась столь лестных отзывов - я не знаю, но! Но если действительно все что написано в книге кажется широким массам столь полезными и неочевидными практиками, то мы все в настолько глубокой жопе, что аж прям ой.
Оценка 2/10