Wiki Category: Дао

разрабы и студенты заипали

без комментариев и оценки:

Вас ли не заебало заигрывать с разработчиками?

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

И мне, честно говоря, поднадоело этим заниматься, сюсюкаться блять. со всеми. Я очень лояльный. Я не выебываюсь, не ору на заказчков в ответ, когда они истерят (хотя иногда очень хочется), многое могу понять с человеческой стороны от подрядчиков. При этом, так или иначе, результат достигается.

Но всему есть предел. Если подрядчик меня подводит или доводит (а довести меня – это надо постараться. Знающие не дадут соврать), то я принимаю решение обратиться к аутсорной конторе. Да, это дороже, да это кот в мешке. Зато без всего этого вот.

И я уверяю вас, очень многие будут выбирать чуть по-дороже, зато без “вот этого вот”. Потому что рано или поздно задолбает огребать от собственников за чужие проебы. Они не мои подчиненные, они подрядчики компании и отвечают перед ней – да. Но я отвечаю перед собственником за сроки и качество их работы. А отвечать за то, на что я не могу напрямую влиять – вертел я это. И многие, многие будут думать так. Никому не интересно постоянное получение пизды за чужие огрехи. И люди будут снижать свои риски. Да, работа с компаниями – это отдельный сорт удовольствия, но если выбрать нормальную, то там куда предсказуемее результат.

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

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

пишет совсем другой

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

Моя университетская должность гораздо ниже, однако и мне постоянно приходится «менять детишкам подгузники».

Даже в драгоценные выходные у меня уходит немало времени на переписку со студентами. Лишь один день для иллюстрации. В первом пришедшем письме студент попросил меня повторить, что я сказала ему про его вчерашнюю презентацию: он вообще-то слышал, что я говорила в классе, но как-то забыл. Другая собиралась встретиться со мной и попросила напомнить номер моего офиса, который есть на университетском сайте. Третий попросил переслать ему материал, который также есть на сайте. Четвертая спросила, можно ли уехать домой на полсеместра раньше, не сдавая экзамена, но чтобы оценка при этом была не ниже четверки.
Вместо того чтобы послать всю эту братию подальше и заняться своей непосредственной работой — написанием статьи, сроки которой поджимают, я сажусь и пишу им письма, вежливые, уважительные, информативные.

…Пару лет назад один мой студент решил не явиться на экзамен, а вместо этого поехать отдыхать в Майями. Когда он узнал, что не сдал курс, то страшно возмутился. Его же не предупредили, что на экзамен надо приходить! С тех пор в моем описании курса появился дополнительный пункт «неявка на экзамен без уважительной причины ведет к несдаче предмета».

Как любое учреждение сферы обслуживания, западный университет действует по принципу «клиент всегда прав». В конце семестра студенты пишут отзывы на курс. Получив негативное замечание, преподаватель обязан заполнить еще одну официальную бумагу — как он собирается реформировать курс, чтобы не допустить подобного отзыва в дальнейшем. И неважно, если замечание будет от вечно сонной двоечницы и будет звучать как «ну, курс вообще был ничего, но как-то не очень вставляло». Долг преподавателя — сформулировать четко и конкретно, что он будет делать, чтобы избежать подобной критики.

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

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

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

Хорошие программисты пишут код, лучшие — тикеты

И заказчики, и программисты привыкли к неформальному общению.

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

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

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

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

Потом проходит 2–3 недели, и мы уже не помним, о чем договорились. Заказчик говорит, что хотел не это, мы пытаемся доказать, что именно это он и просил, выискиваем какое-нибудь упоминание в чате — начинается ловля блох.

Думаю, причина в страхе тикетных систем. Многие программисты, с которыми мы работаем (наверняка, это и вас касается), не умеют, не любят, не хотят формулировать задачи в виде тикета — понятного и краткого.

Людям легче сказать: «Давай поговорим! Проведем митинг, сядем вместе и все решим. За 3 часа поймем друг друга, а потом я пойду и закодирую это. Я буду помнить, о чем мы договорились, и все запрограммирую». Забудем —ничего, встретимся еще раз. И так мы от митинга к митингу как-то протянем.

Это неправильно. Мы, как программисты, должны любое неформальное общение конвертировать в тикеты. Поговорили с клиентом (заказчиком, product-owner’ом, другим программистом), узнали, что нужно поменять — любую коммуникацию конвертируем в тикет ограниченный рамками нашей системы (Jira, GitHub и т.д.), где прописываем: что не работает, как нужно исправить, почему нужно исправить, какая мотивация, и потом по этому тикету работаем.

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

  • Непрерывная разработка — программирование с 9 утра до 5 вечера: пришел, компьютер включил, тут что-то сделал, там, обед, еще покодировал, конец дня — ну ладно, завтра продолжу. То есть программируем, пока есть энергия, время, силы.
  • Инкрементальная разработка другая: есть задача №13, сделаю до конца, а потом посмотрю, какая задача следующая. В этом виде задача (тикет) всегда будет завершен. Зато, если тикета нет, нет сформулированной документированной задачи, проект не двигается — код не пишется, и не появляются pull request.

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

Во втором варианте каждый тикет завершается pull request’ом: вот проблема, ее описание, дискуссия в области этой проблемы, изменение в коде. Pull request отправлен, проверен, принят — тикет закрыт, можно переходить к следующему.

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

Некоторые ошибочно считают, что инкрементальная разработка обязательно означает задачу длиной в 2 недели, и что тикет должен заканчиваться pull request’ом в 5 тысяч измененных строк. Это не инкрементальная разработка. Инкрементальная — это задача на 0,5–2 часа, и в конце pull request из 50-100 строчек кода. Непрерывная наоборот — долго-долго работаете (днями, неделями) и мало что производите.

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

Приведу пример из жизни. Недавно у нас был заказчик, который, как и многие другие, хотел объяснить суть проекта по телефону. Он поговорил по телефону с одним из наших архитекторов несколько раз. Через неделю я обнаружил, что, несмотря на то что идет обсуждение, может быть, даже какой-то код пишется, в системе есть всего один тикет. Это ошибка архитектора, который получал поток информации и не структурировал её. Потом, если в проекте возникнут проблемы, нам нечем будет ответить недовольному клиенту. Мы же не поднимем логи телефонных разговоров.

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

Егор Бугаенко Пять пугающих трендов современной разработки

Как закаляется сталь

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

Читать дальше

20 вещей, которые я вынес за 20 лет в программировании

– Не боритесь с инструментами — библиотеками, языками, платформами — чем бы то ни было. Старайтесь использовать присущие им конструкции
– Вы пишите код не для машин.
– Технический долг как фастфуд: допустим в умеренных количествах, но если войдёт в привычку, не успеете оглянуться, как он убьёт продукт, и это будет больно.
– Хороший код не требует документации, но отличный код задокументирован по определению.
– Никогда не начинайте кодить (разрабатывать какое-то решение), полностью не вникнув в суть задачи.

Читать дальше

Программирование — не тяжелый физический труд, но все равно отстой

Вы полностью компетентны, и все хорошо, и вдруг все ломается.

«Шо за нах?» — восклицаете вы и начинаете отлавливать проблему. Выясняется, что однажды один идиот решил, что раз другой идиот решил, что 1/0 равно бесконечности, он может использовать это как условное обозначение для «бесконечности» для упрощения своего кода. Затем не-идиот справедливо решил, что это идиотизм, то, что должен был решить первый идиот, но поскольку он этого не сделал, не-идиот решил стать козлом и сделать это ошибкой компиляции. Затем он решил никому не говорить, что это ошибка, потому что он козел, и теперь все ваши снежинки — моча, а вы даже не можете найти кошку.

Читать дальше

Тимлид – это сержант

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

Читать дальше

Немного рефлексии на тему неспособности работать в больших компаниях

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

Читать дальше

samdark: Про проектирование и архитектуру

markdown проще рендерить единообразно, удобней хранить и делать diff.
Хороший монолит не хуже микросервисов. Плохие микросервисы с нечёткими границами гораздо хуже монолита.
Кешируйте только когда оптимизации перестали помогать.
Большинство на первый взгляд странных решений в доставшемся вам legacy-проекте там не просто так.

Читать дальше

14 привычек высокоэффективных разработчиков

1. Пишите маленькие методы
2. Давайте содержательные имена
3. Не загромождайте ваши методы множеством параметров
4. Избегайте слишком большого количества методов в классе
5. Используя сторонние библиотеки, пользуйтесь LTS / стабильными релизами
6. Научитесь идентифицировать самые распространенные шаблоны проектирования
7. Всегда помните о разработчике, который придет вам на смену
8. Привыкайте к ударам по вашей гордости
9. Оставьте «кемпинг» более чистым, чем вы его нашли
10. Не бойтесь заниматься вещами, не связанными с написанием кода
11. Будьте фанатом документации
12. Оставляйте себе время на отдых и физическую активность
13. Учитесь отстраняться от личных чувств
14. Давайте хорошие советы

Читать дальше

На смерть Fixed Cost

Alexander Shishenin·Wednesday, February 13, 2019

Давно была мысль написать текст о том, почему разработка по модели Fixed Cost постепенно уходит в прошлое, но после пары диалогов на обедах во время Лидеров России, понял, что проблему многие уже ощущают, но не могут формализовать. Поэтому решил всё же написать, почему идея разработки по ТЗ и как следствие модель Fixed Cost останутся в очень небольшом сегменте рынка.

Для начала опишу ключевые фразы, которые являются маркерами проблемы. “Мы не можем найти программистов на наше замечательное ТЗ!”, “Руководство не понимает, чем заняты разработчики!”, “Да, вы сделали по ТЗ, но у конкурентов ведь лучше! Куда вы смотрели!!!”, “Мы вам выделили огромный бюджет, но после пяти лет разработки продукт не окупается!”, “Мы начали контролировать маржинальность разработки, а они начали крутить каждую гайку по два года!”

На первый взгляд может показаться, что это всё про разное, но на самом деле корень проблемы один. Ещё Брукс в своей книге “Мифический человекомесяц” в заключении писал, что время когда один человек мог уместить в мозг все аспекты цифрового мира, давно канул в прошлое. С тех пор ситуация для сторонников “продуманного плана” стала только хуже. Языков программирования и технологий расплодилось великое множество и даже в своей предметной области уместить всё в голову никто не может.

В результате мы имеем ситуацию, когда создание качественного ТЗ по своей сложности сравнимо с созданием самой системы. Это ооочень долго и ооочень дорого. Сторонники этого метода парируют, что разработка то теперь будет стоить дёшево, но вот только фигушки. Рынок программистов постоянно нагревается, разговоры о том, что он перегрет, среди сторонников ТЗ, идут постоянно, но вот только дефицит кадров такой, что ни о каком остывании пока речи не идёт. В результате, даже если хорошее ТЗ сделано, программистов на него найти сложно. Делать так, как написал другой дядя, с карьерной точки зрения, не имеет никакого смысла. Поэтому этим готовы заниматься только совсем начинающие, за которыми надзор нужен. А надзор сам по себе требует квалификации и желающих им заниматься на рынке не много, и стоят они дорого. Итог для любителей ТЗ очень печальный, им остаются индустрии, где итерации невозможны. Это в первую очередь медицина и космос, но в общей массе проектов, это капля в море.

Вторым важным фактором является предельная зависимость IT проектов от скорости разработки. Это доказал ещё Microsoft в момент своего вертикального взлёта и это ещё во времена офлайн. С приходом интернета понятие скорости разработки перешло на качественно иной уровень. Сейчас схема – сделали за неделю, раскатили на 1% аудитории, посмотрели реакцию, если хорошо, раскатили на 10% аудитории, если хорошо, то раскатили на всех, не вызывает удивления в индустрии.

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

Третьим важным фактором является эффект бабочки в ТЗ. Дело в том, что желание что-то поменять у заказчика возникает регулярно. Этому способствуют действия конкурентов, результаты промежуточных приёмок и много чего ещё. Да и само по себе это желание правильное, но вот только модель fixed cost его не предполагает. Связано это с тем, что атомарные изменения в современных IT системах можно сделать крайне редко. Да и нормальный заказчик смотрит именно ключевой функционал, от которого должна зависеть вся система. Но формальное ТЗ в случае fixed cost это штука плоская. В нём нельзя написать, что этот интерфейс не особо важен для ключевого функционала, согласуем в последний месяц разработки. Каждый элемент должен быть описан заранее. Но вот бац, заказчик осознал что в ключевом функционале есть проблема и её надо поменять. И вот мы видим эффект бабочки или как по всему ТЗ катится цунами обновлений, которые ведь надо согласовать, забюджетировать и много чего ещё. Эксперты и аудиторы потирают руки и прикидывают, какой бонус попросить за внеурочную работу. И так будет каждый раз, когда нужно будет что-то изменить и цена такой итерации совсем не нулевая и в итоге fixed cost может вырасти и в два и более раз. Тем, кто думает, что такое случается только в IT, советую почитать, как строят новый аэропорт Берлина. И это в Германии, которая достаточно прозрачная страна. Поэтому да, помните про эффект бабочки в большом проекте. Он может стоить очень дорого.

Казалось бы, уже этого достаточно, чтобы убить fixed cost, но есть ещё один важнейший фактор. Это техническая сложность систем и предельная зависимость от личной ответственности практически каждого разработчика. В современном IT настолько просто сидеть на зарплате и пилить задачи по плану, что практически все системы контроля рабочего времени работают крайне плохо. Обосновать, почему задача на 1 час, стоит 8 часов, может практически любой программист. Раскрыть его могут только коллеги и иногда руководитель группы. Те, кто выше, практически не имеют шансов предъявить конкретные претензии ощутимому проценту разработчиков.

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

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

Цена акции и общая успешность компании из проблемы далёкого дяди, становится личной шкурной мотивацией. И вот случается чудо, Вася видит, что Петя пилит по восемь часов, то, что надо пилить за час. Ранее его мотивации начать делать то же самое, ничего не мешало. Круговая порука и всё такое. Но вот акции… Если мы будем бездельничать, то опцион не вырастет в цене и шансов стать миллионером не будет. Да, если я стану миллионером, то дядя сверху станет миллиардером, но блин… другого легального способа на простой работе стать миллионером нет. И вот круговая порука ломается, Вася вначале говорит с Петей, если тот не понимает, то с начальником Пети, если тот не понимает, то Вася идёт выше. Вася не боится потерять работу, так как он хороший программист и найти схожую вакансию для него не проблема. То есть хуже ему не станет, даже при увольнении, а вот не потерять возможность стать миллионером, это стоит того чтобы добиться решения проблемы. И вот у нас уже не коллектив исполнителей, а коллектив собственников. Да, им куда сложнее управлять, но зато в нём каждый реально нацелен на рост стоимости компании.

Казалось бы, а какое отношение опционы имеют к fixed cost? Ведь заказная разработка практически не имеет отношения к стоимости компании. Ах да… найм… Чтобы перекрыть бонусы от опционов, основное тело зарплаты надо поднимать до совершенно неприличных размеров, да и то, от проблемы высиживания стула, это не избавит.

В итоге не делать опционы могут позволить себе только проекты, у которых предельно высока нематериальная стоимость. Это в первую очередь социальные проекты, а во вторую оборонка и общегосударственные сервисы, где умелое использование патриотизма исполнителей может давать огромный эффект. Но это всё очень тонкие материи, работать с которыми умеют единицы, да опять-таки, патриотизм и социальная ответственность по фиксированной цене не бывает.
В итоге fixed cost останется только в космосе, медицине и других подобных областях, где итеративность невозможна просто в силу природы этой области. В остальных переход на опционы и схему time and material по сути неизбежен. Те, кто этого не будут делать, рано или поздно проиграют конкуренцию.