Универ
Пост для ребят по-моложе. Навеяно разговором в одном чате. Давайте проясним ситуацию с учёбой в университете. Если вы поступаете в плюс-минус приличный ВУЗ, то есть ровно 2 варианта развития событий.
Вариант первый: вы круглый отличник. Круглые отличники, которые со мной учились, уехали сразу после окончания бакалавриата. В основном в магистратуры зарубежных ВУЗов по грантам. Это один из хороших путей построить достойную карьеру, но вставать на него нужно задолго до абитуры. Чтобы было понятно: если у мамы-папы нет учёной степени, вы не учитесь в гимназии с математическим/языковым уклоном с пятого класса и не прочитали пару хороших книг на английском к 16 годам, то забудьте, вам не сюда.
План Б. Университет — это нетворкинг.
Примеров вам? Да легко. Поинтересуйтесь где началась карьера таких мастодонтов как Михаил Ходорковский и Борис Березовский. Нет, разумеется никто не станет раздавать вам визитки важных людей прямо на входе. Но приличный ВУЗ - хорошая платформа для продуктивных знакомств. Вы находитесь в одном помещении с людьми, через которых можно получить инвестиции, заказы, кадры, опыт и многое другое. Держите это в голове. Кстати Березовский, на секундочку, начинал с того, что внедрял САПРы на АвтоВАЗе, куда пролез через научно-универские связи. Не исключено, что и код писал.
Итак, студенческий у вас на руках. Чем заняться? Для начала решите проблему с учёбой. Все эти лекции-семинары-курсовые будут сильно отвлекать от наведения мостов. И вот вам первый нетворк-квест: познакомиться со старшим поколением. Ребята с 3-4 курса точно знают кто какой предмет ведёт, какие задания надо сдавать, какие конспекты писать, какие предметы можно посещать, а какие — не обязательно. Разыщите их, познакомьтесь и оставьте хорошее впечатление. В принципе, уже на этом можно далеко уехать.
Далее, ваша задача сводится в основном к пьянкам и разговорам с разными важными и не очень людьми. Если вы живёте в общаге, то вам очень повезло. Мой однокурсник сейчас CEO геймдев-конторы. Угадайте кто у него работает на лидских должностях? Правильно. Соседи по общаге, с которыми он всю дорогу поквашивал. А ещё есть курилка. Курилка — золотая жила. Даже если табак совсем не ваше, засветиться там стоит. Все никотинозависимые (и студенты, и преподаватели, и администрация) оказываются рано или поздно в курилке. В бурную молодость, когда я выкуривал по пачке в день, несколько дельных знакомств у меня завязались как раз после стрельбы сигарет.
Надо помнить что ваша группа (от 7 до 30 человек) — всего лишь 2% от контингента ВУЗа. Так же есть другие группы, курсы, потоки и даже другие факультеты. А ещё многие преподаватели совмещают ведение семинаров с работой. А там рукой подать до неплохого трудоустройства.
Очень хорошо если в вашу орбиту попадут люди из научных кругов. Профессура, доктора-кандидаты наук, всякие научные сотрудники, зав. лабораториями и прочая фауна институтов. Вас будут призывать остаться в институте, топить за развитие российской науки и рассказывать какой крутой грант недавно дал РФФИ. Вдохновенно слушайте, кивайте, но проявляйте долю скепсиса: вы же не для того пришли сюда, чтобы провести остаток дней в НИИ за зарплату МНСа, так? Профит от таких знакомств может быть самым разнообразным: от зачёта нахаляву до поездки на научную конференцию в Дрезден за бюджетное бабло. Если вы попали в такой замес и шпрехаете на аглицкой мове — считайте что в ваш трактор уже залит бензин.
Посещайте светские мероприятия. Не надо строить из себя "нитакогокаквсе" (как делал автор этого канала в своё время). Посвяга, медиана, выпускной — вот то, что добавляется в ваш календарь автоматически. Конференции, слёты, симпозиумы... Даже культурные мероприятия вроде концерта сводного хора — всё стоит посещать и не стоять в сторонке, а общаться-общаться и ещё раз общаться. Если вы по натуре сыч-интроверт, то держите в голове, что делается это не из вселенского человеколюбия, а сугубо бизнесу ради. Никогда не знаешь в какой момент какие связи выстрелят и какие знакомства окупятся.
Пост для ребят по-моложе. Навеяно разговором в одном чате. Давайте проясним ситуацию с учёбой в университете. Если вы поступаете в плюс-минус приличный ВУЗ, то есть ровно 2 варианта развития событий.
Вариант первый: вы круглый отличник. Круглые отличники, которые со мной учились, уехали сразу после окончания бакалавриата. В основном в магистратуры зарубежных ВУЗов по грантам. Это один из хороших путей построить достойную карьеру, но вставать на него нужно задолго до абитуры. Чтобы было понятно: если у мамы-папы нет учёной степени, вы не учитесь в гимназии с математическим/языковым уклоном с пятого класса и не прочитали пару хороших книг на английском к 16 годам, то забудьте, вам не сюда.
План Б. Университет — это нетворкинг.
Примеров вам? Да легко. Поинтересуйтесь где началась карьера таких мастодонтов как Михаил Ходорковский и Борис Березовский. Нет, разумеется никто не станет раздавать вам визитки важных людей прямо на входе. Но приличный ВУЗ - хорошая платформа для продуктивных знакомств. Вы находитесь в одном помещении с людьми, через которых можно получить инвестиции, заказы, кадры, опыт и многое другое. Держите это в голове. Кстати Березовский, на секундочку, начинал с того, что внедрял САПРы на АвтоВАЗе, куда пролез через научно-универские связи. Не исключено, что и код писал.
Итак, студенческий у вас на руках. Чем заняться? Для начала решите проблему с учёбой. Все эти лекции-семинары-курсовые будут сильно отвлекать от наведения мостов. И вот вам первый нетворк-квест: познакомиться со старшим поколением. Ребята с 3-4 курса точно знают кто какой предмет ведёт, какие задания надо сдавать, какие конспекты писать, какие предметы можно посещать, а какие — не обязательно. Разыщите их, познакомьтесь и оставьте хорошее впечатление. В принципе, уже на этом можно далеко уехать.
Далее, ваша задача сводится в основном к пьянкам и разговорам с разными важными и не очень людьми. Если вы живёте в общаге, то вам очень повезло. Мой однокурсник сейчас CEO геймдев-конторы. Угадайте кто у него работает на лидских должностях? Правильно. Соседи по общаге, с которыми он всю дорогу поквашивал. А ещё есть курилка. Курилка — золотая жила. Даже если табак совсем не ваше, засветиться там стоит. Все никотинозависимые (и студенты, и преподаватели, и администрация) оказываются рано или поздно в курилке. В бурную молодость, когда я выкуривал по пачке в день, несколько дельных знакомств у меня завязались как раз после стрельбы сигарет.
Надо помнить что ваша группа (от 7 до 30 человек) — всего лишь 2% от контингента ВУЗа. Так же есть другие группы, курсы, потоки и даже другие факультеты. А ещё многие преподаватели совмещают ведение семинаров с работой. А там рукой подать до неплохого трудоустройства.
Очень хорошо если в вашу орбиту попадут люди из научных кругов. Профессура, доктора-кандидаты наук, всякие научные сотрудники, зав. лабораториями и прочая фауна институтов. Вас будут призывать остаться в институте, топить за развитие российской науки и рассказывать какой крутой грант недавно дал РФФИ. Вдохновенно слушайте, кивайте, но проявляйте долю скепсиса: вы же не для того пришли сюда, чтобы провести остаток дней в НИИ за зарплату МНСа, так? Профит от таких знакомств может быть самым разнообразным: от зачёта нахаляву до поездки на научную конференцию в Дрезден за бюджетное бабло. Если вы попали в такой замес и шпрехаете на аглицкой мове — считайте что в ваш трактор уже залит бензин.
Посещайте светские мероприятия. Не надо строить из себя "нитакогокаквсе" (как делал автор этого канала в своё время). Посвяга, медиана, выпускной — вот то, что добавляется в ваш календарь автоматически. Конференции, слёты, симпозиумы... Даже культурные мероприятия вроде концерта сводного хора — всё стоит посещать и не стоять в сторонке, а общаться-общаться и ещё раз общаться. Если вы по натуре сыч-интроверт, то держите в голове, что делается это не из вселенского человеколюбия, а сугубо бизнесу ради. Никогда не знаешь в какой момент какие связи выстрелят и какие знакомства окупятся.
Принимать ли участие во всяких движухах вроде студсовета или того же хора — вопрос открытый. Если вам в кайф — принимайте. Но лично я бы ставил на увеличение количества людей, вовлечённых в ваш круг знакомств, поэтому рекомендую всё же менять компашки время от времени и не засиживаться на одном месте.
Двигаться, в общем надо. Двигайтесь. Непрерывно двигайтесь.
Ад пожирает праздных.
Такие дела.
Двигаться, в общем надо. Двигайтесь. Непрерывно двигайтесь.
Ад пожирает праздных.
Такие дела.
Смутное время
Мне кажется, что мы ещё не до конца осознали новую пост-COVID-ную реальность. Разработчики радуются внезапно открывшемуся широкому рынку удалёнки, возможности сидеть возле холодильника да ещё и коньюнктурно подскочившей З/П. Но если так подумать, то радоваться здесь особо нечему. Я поясню ход своих мыслей.
Если честно, я бы не стал рассчитывать что удалёнка — это навсегда. Сами посудите: деньги в собак-френдли офисы с гамаками и кикерами уже вбуханы, а пустые здания на балансе (особенно если они в аренде) — чистый убыток. Продавать огромные офис-спейсы и переходить на полную удалёнку FAANG-у тоже не с руки. На такие площади сложно найти покупателя. А если скинут по бросовой цене, то прикиньте как обвалится рынок недвижки в Калифорнии? Это же пост-индустриальный Детроит! Опять грёбаный киберпанк! Однако, в рынке недвижимости я не секу, поэтому никаких прогнозов — одни фантазии.
Поэтому, давайте всё же предположим что удалёнка — это навсегда. А коль так, то с карьерой у разработчиков намечаются огромные проблемы. "По скайпу" повышать всё же не принято, особенно до руководящих должностей. Получается что работа разраба-удалёнщика сводится к бесконечной сортировке тикетов. При том никакой возможности как-то повлиять на содержимое этих тикетов у разраба нет и не предвидится. Мнение JSONопогрузчика и кнопкопокрасчика никого не волнует, даже если он старший.
В мелких full-remote компаниях на руководящих должностях плотно укоренятся сватья-братья-друзья фаундеров. В крупных компаниях решения по-прежнему будут приниматься лично в офисах и зачастую в странах, в которые у вас всё равно нет визы.
Недавно Яндекс срезал Владу Тену половину рейта, хотя тот, я уверен, прошёл идеально все кодинговые интервью. Влад хотел релоцироваться в Москву, но IT-гигант обломал его по деньгам. Мне сдаётся, что это было сделано по одной простой причине: Влад из Узбекистана. И его профессиональные качества не имеют к этом факту ни малейшего отношения. Чуете запахло территориальной дискриминацией?
И это только начало. Работодатели быстро смекнут, что разрабам из глубинки можно платить гроши и они будут соглашаться потому что всё лучше чем собирать хлопок или работать продавцом-консультантом. Ну и стоимость жизни в регионах по-ниже. Только вот до стоимости жизни, скажем, в Индии нам ещё демпинговать и демпинговать. А с развитием удалённого обучения исчезнет последнее преимущество разработчиков из пост-СССР: крепкая инженерная школа. Какой от неё будет прок если любой индус сможет пройти гарвардский курс?
Второй тренд, с которым мы пересекаемся — это преславутые докерокубернетисы, "не-изобрети-велосипед" и no-code. По сути это упрощение разработки. Чтобы софт можно было не с нуля писать, а собирать из готовых кирпичиков. No-code уверенно двигает разработку в сторону конвейера. И для работы на этом конвейере можно готовить дешёвую рабочую силу, которая как раз и будет жить в регионах, собирать из этих кирпичиков готовые решения, грепать логи и получать плошку риса.
За что будут платить хорошие деньги в таких условиях? А хорошие деньги платить будут только лидам, архитектам и прочим прорабам джейсоноукладчиков. И туда, как выше было описано, можно будет пробиться или по знакомству, если компания маленькая, а если большая — только лично.
Поэтому я сейчас прорабатываю два варианта, чтобы не оказаться в интересном положении через пяток лет. Я делаю свой кирпичик (Reinforced.Lattice) и параллельно получаю вторую вышку (менеджерскую) в Питере.
А вы?
Спасибо gotonomad за то, что натолкнула на мысль.
Такие дела
Мне кажется, что мы ещё не до конца осознали новую пост-COVID-ную реальность. Разработчики радуются внезапно открывшемуся широкому рынку удалёнки, возможности сидеть возле холодильника да ещё и коньюнктурно подскочившей З/П. Но если так подумать, то радоваться здесь особо нечему. Я поясню ход своих мыслей.
Если честно, я бы не стал рассчитывать что удалёнка — это навсегда. Сами посудите: деньги в собак-френдли офисы с гамаками и кикерами уже вбуханы, а пустые здания на балансе (особенно если они в аренде) — чистый убыток. Продавать огромные офис-спейсы и переходить на полную удалёнку FAANG-у тоже не с руки. На такие площади сложно найти покупателя. А если скинут по бросовой цене, то прикиньте как обвалится рынок недвижки в Калифорнии? Это же пост-индустриальный Детроит! Опять грёбаный киберпанк! Однако, в рынке недвижимости я не секу, поэтому никаких прогнозов — одни фантазии.
Поэтому, давайте всё же предположим что удалёнка — это навсегда. А коль так, то с карьерой у разработчиков намечаются огромные проблемы. "По скайпу" повышать всё же не принято, особенно до руководящих должностей. Получается что работа разраба-удалёнщика сводится к бесконечной сортировке тикетов. При том никакой возможности как-то повлиять на содержимое этих тикетов у разраба нет и не предвидится. Мнение JSONопогрузчика и кнопкопокрасчика никого не волнует, даже если он старший.
В мелких full-remote компаниях на руководящих должностях плотно укоренятся сватья-братья-друзья фаундеров. В крупных компаниях решения по-прежнему будут приниматься лично в офисах и зачастую в странах, в которые у вас всё равно нет визы.
Недавно Яндекс срезал Владу Тену половину рейта, хотя тот, я уверен, прошёл идеально все кодинговые интервью. Влад хотел релоцироваться в Москву, но IT-гигант обломал его по деньгам. Мне сдаётся, что это было сделано по одной простой причине: Влад из Узбекистана. И его профессиональные качества не имеют к этом факту ни малейшего отношения. Чуете запахло территориальной дискриминацией?
И это только начало. Работодатели быстро смекнут, что разрабам из глубинки можно платить гроши и они будут соглашаться потому что всё лучше чем собирать хлопок или работать продавцом-консультантом. Ну и стоимость жизни в регионах по-ниже. Только вот до стоимости жизни, скажем, в Индии нам ещё демпинговать и демпинговать. А с развитием удалённого обучения исчезнет последнее преимущество разработчиков из пост-СССР: крепкая инженерная школа. Какой от неё будет прок если любой индус сможет пройти гарвардский курс?
Второй тренд, с которым мы пересекаемся — это преславутые докерокубернетисы, "не-изобрети-велосипед" и no-code. По сути это упрощение разработки. Чтобы софт можно было не с нуля писать, а собирать из готовых кирпичиков. No-code уверенно двигает разработку в сторону конвейера. И для работы на этом конвейере можно готовить дешёвую рабочую силу, которая как раз и будет жить в регионах, собирать из этих кирпичиков готовые решения, грепать логи и получать плошку риса.
За что будут платить хорошие деньги в таких условиях? А хорошие деньги платить будут только лидам, архитектам и прочим прорабам джейсоноукладчиков. И туда, как выше было описано, можно будет пробиться или по знакомству, если компания маленькая, а если большая — только лично.
Поэтому я сейчас прорабатываю два варианта, чтобы не оказаться в интересном положении через пяток лет. Я делаю свой кирпичик (Reinforced.Lattice) и параллельно получаю вторую вышку (менеджерскую) в Питере.
А вы?
Спасибо gotonomad за то, что натолкнула на мысль.
Такие дела
Ещё раз о софт-скиллах
Как вы знаете, я получаю менеджерское образование в Питере. Это серьёзное учебное заведение, без лишнего буллшита дающее хорошие знания кратко и по делу. Рекламировать бренд я тут не буду. Возможно, сделаю это позже.
Так вот. Вы будете смеяться, но именно там мне объяснили откуда взялось требование софт-скиллов в IT. Всё оказалось проще пареной репы. Дело тут в матричной структуре управления. Вот, почитайте про неё подробнее. Именно такая структура наводится в большинстве средних IT-компаний, потому что это единственное что хоть как-то работает. Если в EPAM это всё чётко разведено грамотными консультантами, то там где труба по-ниже а дым по-жиже, слабые матричные структуры создаются естественным путём от сохи руководителями, MBA-ев не кончавшими. Играют, короче, как умеют.
В чём суть матричной структуры? В том, что компания разрезается по горизонтали и по вертикали. Оргструктура получается похожа на таблицу, но это слишком скучное слово, поэтому "матрица".
По вертикали у нас — функциональные направления. Иногда их называют "гильдия". Фронтенд, бекенд, DBA, DevOps, мобильные разработчики. От джунов до сениоров. В грамотно построенной матрице есть руководители функциональных направлений. Условно — самый-главный-фроентендер, самый-главный-девопс ну и так далее. Терминология может разниться, но мы назовём людей наверху "архитектами".
По логике вещей попадает на эту должность гуру направления и его роль сводится к тому, чтобы возиться с людьми, распространять свой опыт (менторство, ревью пулл-реквестов), участвовать на правах консультанта в построении продуктов, уберегая молодых бойцов от граблей и проектировать решения, на что многие кладут писюн.
По горизонтали же компания делится на проекты. У каждого проекта есть свой проектный менеджер (который сейчас в дань моде вытесняется продакт-менеджером). Этот чувак может ни бельмеса не смыслить в разработке. Его задача сводится, грубо говоря, к getting things done. По всем пробежать, всех напрячь, коммуникации скоммуницировать, вопросики порешать, фуру на владик отправить.
И тут теория нас научает: при таком раскладе неизбежны конфликты двойного подчинения.
Шо цэ? Ну смотрите: проекту нужны люди. Их выдёргивают из функциональных подразделений. PM идёт на поклон к архитекту и говорит "дай фронтендера!". И тут случается первый конфликт двойного подчинения. Ответ архитекта по умолчанию — "не дам". Или "бери джунов". Почему? Ну потому что KPI по людям у архитекта такие. Джунам надо опыта добрать, а хороших людей хочется припасти для более важных проектов. А для хорошего архитекта всегда будут более важные проекты чем какая-то дичь, которую тащит PM.
Второй конфликт случается когда разрабы начинают работать над проектом. PM давит со сроками и велит забить на качество, а архитект учил другому. Субъективно разрабу это ощущается как шизофрения руководства. "Што вы? Кто вы? Идите подеритесь уже!" — вполне справедливо думает разраб. На выходе из проекта ситуация тоже турбулентная. Вроде как у человека был PM, он вроде остался в чате, периодически что-то написывает и просит помочь по мелочи, но архитект помогать не велит. А велит, скажем, техдолг разгребать во внутреннем проекте. Снова здорово: "договоритесь уже между собой, ушлёпки!".
Работать это может только при поголовной адекватности всех участвующих. Но написать "не быть мудилой" в вакансии нельзя, поэтому пишут "требуются софт-скиллз".
Проблемы очевидны, но на практике всё как всегда через жопу: низкого качества руководство слабо понимает как тут сработают софт-скиллз, HR с дипломом пед. вуза села Верхняя Пышма тоже не шарит что происходит, а поэтому все дружно не понимают каких людей искать. И то, что в первую очередь хорошие софт-скиллз должны быть у PM-а и архитекта — этого так же никто не разумеет.
Такие дела
Как вы знаете, я получаю менеджерское образование в Питере. Это серьёзное учебное заведение, без лишнего буллшита дающее хорошие знания кратко и по делу. Рекламировать бренд я тут не буду. Возможно, сделаю это позже.
Так вот. Вы будете смеяться, но именно там мне объяснили откуда взялось требование софт-скиллов в IT. Всё оказалось проще пареной репы. Дело тут в матричной структуре управления. Вот, почитайте про неё подробнее. Именно такая структура наводится в большинстве средних IT-компаний, потому что это единственное что хоть как-то работает. Если в EPAM это всё чётко разведено грамотными консультантами, то там где труба по-ниже а дым по-жиже, слабые матричные структуры создаются естественным путём от сохи руководителями, MBA-ев не кончавшими. Играют, короче, как умеют.
В чём суть матричной структуры? В том, что компания разрезается по горизонтали и по вертикали. Оргструктура получается похожа на таблицу, но это слишком скучное слово, поэтому "матрица".
По вертикали у нас — функциональные направления. Иногда их называют "гильдия". Фронтенд, бекенд, DBA, DevOps, мобильные разработчики. От джунов до сениоров. В грамотно построенной матрице есть руководители функциональных направлений. Условно — самый-главный-фроентендер, самый-главный-девопс ну и так далее. Терминология может разниться, но мы назовём людей наверху "архитектами".
По логике вещей попадает на эту должность гуру направления и его роль сводится к тому, чтобы возиться с людьми, распространять свой опыт (менторство, ревью пулл-реквестов), участвовать на правах консультанта в построении продуктов, уберегая молодых бойцов от граблей и проектировать решения, на что многие кладут писюн.
По горизонтали же компания делится на проекты. У каждого проекта есть свой проектный менеджер (который сейчас в дань моде вытесняется продакт-менеджером). Этот чувак может ни бельмеса не смыслить в разработке. Его задача сводится, грубо говоря, к getting things done. По всем пробежать, всех напрячь, коммуникации скоммуницировать, вопросики порешать, фуру на владик отправить.
И тут теория нас научает: при таком раскладе неизбежны конфликты двойного подчинения.
Шо цэ? Ну смотрите: проекту нужны люди. Их выдёргивают из функциональных подразделений. PM идёт на поклон к архитекту и говорит "дай фронтендера!". И тут случается первый конфликт двойного подчинения. Ответ архитекта по умолчанию — "не дам". Или "бери джунов". Почему? Ну потому что KPI по людям у архитекта такие. Джунам надо опыта добрать, а хороших людей хочется припасти для более важных проектов. А для хорошего архитекта всегда будут более важные проекты чем какая-то дичь, которую тащит PM.
Второй конфликт случается когда разрабы начинают работать над проектом. PM давит со сроками и велит забить на качество, а архитект учил другому. Субъективно разрабу это ощущается как шизофрения руководства. "Што вы? Кто вы? Идите подеритесь уже!" — вполне справедливо думает разраб. На выходе из проекта ситуация тоже турбулентная. Вроде как у человека был PM, он вроде остался в чате, периодически что-то написывает и просит помочь по мелочи, но архитект помогать не велит. А велит, скажем, техдолг разгребать во внутреннем проекте. Снова здорово: "договоритесь уже между собой, ушлёпки!".
Работать это может только при поголовной адекватности всех участвующих. Но написать "не быть мудилой" в вакансии нельзя, поэтому пишут "требуются софт-скиллз".
Проблемы очевидны, но на практике всё как всегда через жопу: низкого качества руководство слабо понимает как тут сработают софт-скиллз, HR с дипломом пед. вуза села Верхняя Пышма тоже не шарит что происходит, а поэтому все дружно не понимают каких людей искать. И то, что в первую очередь хорошие софт-скиллз должны быть у PM-а и архитекта — этого так же никто не разумеет.
Такие дела
Занимательная арифметика
Пост не про IT, сразу предупреждаю.
Гулял с мамой по Питеру. Встретил парней, которые дают сфотаться с енотом. Прям втюхивают. Ну это знаете, как вот эти все бесконечные костюмированные Петры I и Екатерины, от которых заколебёшься отбиваться.
Быстро вяснилось, что енота предсказуемо зовут Ракета, а парни просят за фотографию 1 тысячу рублей с детей и 2 тысячи со взрослых.
А давайте-ка прикинем бизнес-план на коленке. Грубо предположим, что интеракция с Ракетой занимает 10 минут. Итого в час происходит 6 интеракций. Ракета честный енот и работает согласно ТКРФ по 8 часов с перерывом на обед. В денежном выражении это 2000 * 6 * 8 = 96 000 рублей в день. Округлим до 100 000. То есть Ракета, строго придерживаясь того же ТКРФ и имея 2 законных выходных зарабатывает полмиллиона рублей в неделю. То есть, 2 миллиона в месяц. Считаем грубо, что туристический сезон в реалиях Питера — ну пусть месяца 4. Итого Ракета не напрягаясь поднимает 8 миллионов рублей в сезон.
К Ракете вопросов никаких. Есть вопрос к парням: вы, блин, где свой Майбах в центре Питера средь бела дня припарковали, м?
Ну а люди из IT пусть сделают выводы сами.
Такие дела
Пост не про IT, сразу предупреждаю.
Гулял с мамой по Питеру. Встретил парней, которые дают сфотаться с енотом. Прям втюхивают. Ну это знаете, как вот эти все бесконечные костюмированные Петры I и Екатерины, от которых заколебёшься отбиваться.
Быстро вяснилось, что енота предсказуемо зовут Ракета, а парни просят за фотографию 1 тысячу рублей с детей и 2 тысячи со взрослых.
А давайте-ка прикинем бизнес-план на коленке. Грубо предположим, что интеракция с Ракетой занимает 10 минут. Итого в час происходит 6 интеракций. Ракета честный енот и работает согласно ТКРФ по 8 часов с перерывом на обед. В денежном выражении это 2000 * 6 * 8 = 96 000 рублей в день. Округлим до 100 000. То есть Ракета, строго придерживаясь того же ТКРФ и имея 2 законных выходных зарабатывает полмиллиона рублей в неделю. То есть, 2 миллиона в месяц. Считаем грубо, что туристический сезон в реалиях Питера — ну пусть месяца 4. Итого Ракета не напрягаясь поднимает 8 миллионов рублей в сезон.
К Ракете вопросов никаких. Есть вопрос к парням: вы, блин, где свой Майбах в центре Питера средь бела дня припарковали, м?
Ну а люди из IT пусть сделают выводы сами.
Такие дела
Митя
Зарисовочка вам из жизни.
Митя был не юнга, не адмирал... А обычный молодой .NET-разработчик средней руки с горящими глазами. Митя очень любил C# и следил за всеми новинками от Microsoft. Так же Митя имел классическое образование от Computer Science и свято чтил лучшие практики программирования и проектирования. Холодными осенними вечерами он ревьюил пулл-реквесты и периодически незло журил коллег за неправильное использование фич C#, за дурное именование, кое Митя на дух не переносил и за копипаст кода. Митя считал что лучше не написать никакой код, нежели написать плохой. Таков был Митя.
На работе Митя отвечал за важный кусок бизнес-логики. Он исполнил его в самом лучшем виде, грамотно вплёл в него лучшие практики, покрыл unit-тестами и написал кучу комментариев. Этот замечательный, декомпозированный на слои и использующий асинхронный доступ к БД кусок системы был личной гордостью Мити. "Во всём должен быть порядок" — справедливо полагал Митя.
У продуктовой компании, где работал Митя было шикарное и красивое web-приложение для внешних пользователей. А ещё было старое и некрасивое приложение-backoffice. Ну знаете, админка без внешнего доступа где можно банить неугодных пользователей, загружать новый контент и смотреть статистику. Пользовались оным контент-менеджеры, модераторы и тётушки-бухгалтеры для построения квартальных отчётов.
Директор компании в своё время волевым решением сконцентрировал все силы, деньги и лучшие кадры на web-приложении для внешних пользователей. А разработку backoffice проаутсорсили в компанию из чуть менее благополучной страны, где за разработку взялись вчерашние студенты. Вышло криво и неудобно, зато быстро и без драмы в финансовых отчётах. Впрочем, то были дела давно минувших дней. Ныне код backoffice лежал в отдельном репозитории, менялся раз в год по праздникам и деплоился вручную. Всё плюс-минус работало и всех устраивало.
Однажды начальство поручило Мите задачу: в backoffice нужно интегрировать часть функциональности из той бизнес-логики за которую отвечает Митя. Мол, ты, Митя, в этом разбираешься — тебе и карты в руки. Митя взял под козырёк и перенёс тикет в In Progress. Чтобы не дублировать код, собрал свой любимый кусок бизнес-логики в NuGet-пакет и пошёл с ним в backoffice.
Пришёл Митя в backoffice, а там — старый ASP .NET MVC, который ещё до асинков появился. И тут Митю и накрыло экзистенциальным кризисом. Переделать бизнес-логику на синхронную нельзя. Во-первых, асинки — это бэст практис, во-вторых дублировать код плохо. Поставить на тасках .Wait() нельзя — задедлочится в виду особенностей ASP.NET-ной многопоточности. На предложение переписать backoffice под новую версию MVC начальство покрутило пальцем у виска.
Митя погоревал до весны, после чего уволился и уехал в деревню, разводить сусликов на мясо. И больше никогда не приближался к программированию. Так-то.
Чему нас учит эта история?
Во-первых, бедный Митя в виду молодости не знал о таком понятии как трейд-офф. Суть трейд-оффов состоит в том, что иногда нужно отказаться от одних важных и нужных вещей, чтобы получить другие. В шахматах это называется гамбит.
Во-вторых, Митя, очевидно, слишком серьёзно воспринимал бэст практики. Предписания — это, конечно, удобно. Но в нашей работе, знаете, готовых рецептов мало. Чтобы быть хорошим разработчиком — увы, мало знать лучшие практики. Надо понимать как они работают, а главное — что они вам дадут конкретно в вашей ситуации. И что отнимут. Бэст-практики сделали Митю похожим на обезьяну, засунувшую лапу в дупло, в которое охотник положил банан. Лапа застряла, а отпустить банан противоречит системе ценностей обезьяны.
В-третьих, наша профессия не изотропна.
Последовательность хороших и правильных "в моменте" решений далеко не всегда ведёт к хорошему и правильному результату. И ничего с этим не поделать.
Такие дела
Зарисовочка вам из жизни.
Митя был не юнга, не адмирал... А обычный молодой .NET-разработчик средней руки с горящими глазами. Митя очень любил C# и следил за всеми новинками от Microsoft. Так же Митя имел классическое образование от Computer Science и свято чтил лучшие практики программирования и проектирования. Холодными осенними вечерами он ревьюил пулл-реквесты и периодически незло журил коллег за неправильное использование фич C#, за дурное именование, кое Митя на дух не переносил и за копипаст кода. Митя считал что лучше не написать никакой код, нежели написать плохой. Таков был Митя.
На работе Митя отвечал за важный кусок бизнес-логики. Он исполнил его в самом лучшем виде, грамотно вплёл в него лучшие практики, покрыл unit-тестами и написал кучу комментариев. Этот замечательный, декомпозированный на слои и использующий асинхронный доступ к БД кусок системы был личной гордостью Мити. "Во всём должен быть порядок" — справедливо полагал Митя.
У продуктовой компании, где работал Митя было шикарное и красивое web-приложение для внешних пользователей. А ещё было старое и некрасивое приложение-backoffice. Ну знаете, админка без внешнего доступа где можно банить неугодных пользователей, загружать новый контент и смотреть статистику. Пользовались оным контент-менеджеры, модераторы и тётушки-бухгалтеры для построения квартальных отчётов.
Директор компании в своё время волевым решением сконцентрировал все силы, деньги и лучшие кадры на web-приложении для внешних пользователей. А разработку backoffice проаутсорсили в компанию из чуть менее благополучной страны, где за разработку взялись вчерашние студенты. Вышло криво и неудобно, зато быстро и без драмы в финансовых отчётах. Впрочем, то были дела давно минувших дней. Ныне код backoffice лежал в отдельном репозитории, менялся раз в год по праздникам и деплоился вручную. Всё плюс-минус работало и всех устраивало.
Однажды начальство поручило Мите задачу: в backoffice нужно интегрировать часть функциональности из той бизнес-логики за которую отвечает Митя. Мол, ты, Митя, в этом разбираешься — тебе и карты в руки. Митя взял под козырёк и перенёс тикет в In Progress. Чтобы не дублировать код, собрал свой любимый кусок бизнес-логики в NuGet-пакет и пошёл с ним в backoffice.
Пришёл Митя в backoffice, а там — старый ASP .NET MVC, который ещё до асинков появился. И тут Митю и накрыло экзистенциальным кризисом. Переделать бизнес-логику на синхронную нельзя. Во-первых, асинки — это бэст практис, во-вторых дублировать код плохо. Поставить на тасках .Wait() нельзя — задедлочится в виду особенностей ASP.NET-ной многопоточности. На предложение переписать backoffice под новую версию MVC начальство покрутило пальцем у виска.
Митя погоревал до весны, после чего уволился и уехал в деревню, разводить сусликов на мясо. И больше никогда не приближался к программированию. Так-то.
Чему нас учит эта история?
Во-первых, бедный Митя в виду молодости не знал о таком понятии как трейд-офф. Суть трейд-оффов состоит в том, что иногда нужно отказаться от одних важных и нужных вещей, чтобы получить другие. В шахматах это называется гамбит.
Во-вторых, Митя, очевидно, слишком серьёзно воспринимал бэст практики. Предписания — это, конечно, удобно. Но в нашей работе, знаете, готовых рецептов мало. Чтобы быть хорошим разработчиком — увы, мало знать лучшие практики. Надо понимать как они работают, а главное — что они вам дадут конкретно в вашей ситуации. И что отнимут. Бэст-практики сделали Митю похожим на обезьяну, засунувшую лапу в дупло, в которое охотник положил банан. Лапа застряла, а отпустить банан противоречит системе ценностей обезьяны.
В-третьих, наша профессия не изотропна.
Последовательность хороших и правильных "в моменте" решений далеко не всегда ведёт к хорошему и правильному результату. И ничего с этим не поделать.
Такие дела
Продажники
Вот уж где точно филиал ада на земле — так это в продажах.
Тут важно не путать. Есть маркетологи, которые строят воронки, продумывают где и какую рекламу разместить, какой текст на ней написать и как увеличить её охват. Персонально каждого клиента они не касаются. Их задача — лидогенерация. То есть чтобы "лиды" (потенциальные клиенты, которые ещё не понимают что они клиенты) пришли к дверям компании. Желательно толпой. И желательно большой. На этом полномочия маркетинга всё.
А вот после того, как клиент переступил порог компании, он уже попадает в руки продажника. Задача этого кадра состоит в том, чтобы всеми правдами и неправдами сделать так, чтобы клиент ушёл, оставив в компании деньги. В ход идёт всё подряд: уговоры, харизма, логика, распитие коньяка с клиентом, ценовые условия, дополнительные предложения, милый вид, приятный голос. Всё, что угодно лишь бы клиент оставил деньги и ушёл. Но так, чтобы вернулся. Эти ребята умеют убеждать.
Так как продажники непосредственно имеют дело с деньгами и клиентами, то кухня у них специфическая. Ведь у них в руках стратегическая информация: внешние цены на товары и услуги, сроки поставок, непосредственные контакты клиентов с именами-фамилиями и номерами телефонов, бухгалтерские подробности сделок. IT-людям на заметку: вы думаете что вы владеете какими-то секретами компании? Ага, разбежались. У продажников самый сок.
Плюс к тому же, сами продажники, обычно, ребята довольно ушлые. Со своеобразной залихвастской ебанцой. При горящей сделке, например, они могут побежать к кому-нибудь напрямую "внутрь" компании и договориться о каких-либо специальных условиях для клиента мимо непосредственного руководства. Поэтому при управлении целым отделом таких кадров, каждого надлежит держать в ежовых рукавицах. И руководители придумывают продажникам разное развлекалово: чёткие планы, за невыполнение которых увольняют не думая, разные вариации систем оклад+премия с хитрыми грейдами и ступеньками. Всё это жирно присыпается сверху KPI-ами дабы балду не пинали и время от времени поддерживается живительными пиздюлями со стороны непосредственно начальника.
Как вы поняли, построение отдела продаж требует, выразимся так, крайне специальных навыков от руководителя. Я бы описал это так: дивная внешняя милота при абсолютной внутренней беспощадности и готовности к драконовским мерам. В порядке вещей: всякие-разные системы трекинга рабочего времени, корпоративные телефоны, ограничение доступа в Интернет, правило "пустого рабочего стола". В некоторых компаниях сотрудникам отдела продаж выдают отдельные электронные пропуска, по которым им закрыт доступ во все остальные кабинеты физически. Случаев установки решёток на окна пока не зафиксировано.
Если RnD в компании можно сравнить с тихим-уютным стойлом, в котором не спеша пасутся коты и тихонько в уголке варится продукт, то продажи — это дикие джунгли, по которым носятся туда-сюда взъерошенные орангутаны и так и норовят огреть кого-нибудь по башке свежеотёсанной дубиной.
К чему я вам это, собственно, рассказываю? А чтобы показать насколько разработка и продажи — разные вещи.
Если вы — рядовой разработчик, а ваш начальник или PM имеет опыт работы в продажах — бегите, глупцы!
Продажи — это печать на всю жизнь. Человека, прошедшего этот адок, на пушечный выстрел нельзя подпускать к мозгоёмкой работе никогда, ни при каких условиях. Тем более давать ему руководить чем-либо, связанным с разработкой.
Такие дела
Вот уж где точно филиал ада на земле — так это в продажах.
Тут важно не путать. Есть маркетологи, которые строят воронки, продумывают где и какую рекламу разместить, какой текст на ней написать и как увеличить её охват. Персонально каждого клиента они не касаются. Их задача — лидогенерация. То есть чтобы "лиды" (потенциальные клиенты, которые ещё не понимают что они клиенты) пришли к дверям компании. Желательно толпой. И желательно большой. На этом полномочия маркетинга всё.
А вот после того, как клиент переступил порог компании, он уже попадает в руки продажника. Задача этого кадра состоит в том, чтобы всеми правдами и неправдами сделать так, чтобы клиент ушёл, оставив в компании деньги. В ход идёт всё подряд: уговоры, харизма, логика, распитие коньяка с клиентом, ценовые условия, дополнительные предложения, милый вид, приятный голос. Всё, что угодно лишь бы клиент оставил деньги и ушёл. Но так, чтобы вернулся. Эти ребята умеют убеждать.
Так как продажники непосредственно имеют дело с деньгами и клиентами, то кухня у них специфическая. Ведь у них в руках стратегическая информация: внешние цены на товары и услуги, сроки поставок, непосредственные контакты клиентов с именами-фамилиями и номерами телефонов, бухгалтерские подробности сделок. IT-людям на заметку: вы думаете что вы владеете какими-то секретами компании? Ага, разбежались. У продажников самый сок.
Плюс к тому же, сами продажники, обычно, ребята довольно ушлые. Со своеобразной залихвастской ебанцой. При горящей сделке, например, они могут побежать к кому-нибудь напрямую "внутрь" компании и договориться о каких-либо специальных условиях для клиента мимо непосредственного руководства. Поэтому при управлении целым отделом таких кадров, каждого надлежит держать в ежовых рукавицах. И руководители придумывают продажникам разное развлекалово: чёткие планы, за невыполнение которых увольняют не думая, разные вариации систем оклад+премия с хитрыми грейдами и ступеньками. Всё это жирно присыпается сверху KPI-ами дабы балду не пинали и время от времени поддерживается живительными пиздюлями со стороны непосредственно начальника.
Как вы поняли, построение отдела продаж требует, выразимся так, крайне специальных навыков от руководителя. Я бы описал это так: дивная внешняя милота при абсолютной внутренней беспощадности и готовности к драконовским мерам. В порядке вещей: всякие-разные системы трекинга рабочего времени, корпоративные телефоны, ограничение доступа в Интернет, правило "пустого рабочего стола". В некоторых компаниях сотрудникам отдела продаж выдают отдельные электронные пропуска, по которым им закрыт доступ во все остальные кабинеты физически. Случаев установки решёток на окна пока не зафиксировано.
Если RnD в компании можно сравнить с тихим-уютным стойлом, в котором не спеша пасутся коты и тихонько в уголке варится продукт, то продажи — это дикие джунгли, по которым носятся туда-сюда взъерошенные орангутаны и так и норовят огреть кого-нибудь по башке свежеотёсанной дубиной.
К чему я вам это, собственно, рассказываю? А чтобы показать насколько разработка и продажи — разные вещи.
Если вы — рядовой разработчик, а ваш начальник или PM имеет опыт работы в продажах — бегите, глупцы!
Продажи — это печать на всю жизнь. Человека, прошедшего этот адок, на пушечный выстрел нельзя подпускать к мозгоёмкой работе никогда, ни при каких условиях. Тем более давать ему руководить чем-либо, связанным с разработкой.
Такие дела
Творческий отпуск
Я немного завяз в рутинных делах, поэтому вместо того, чтобы постить проходную чушь, возьму-ка я пару недель творческого отпуска.
Впереди ещё много хороших текстов. Не переключайтесь.
Такие дела
Я немного завяз в рутинных делах, поэтому вместо того, чтобы постить проходную чушь, возьму-ка я пару недель творческого отпуска.
Впереди ещё много хороших текстов. Не переключайтесь.
Такие дела
На злобу дня
Подписывайтесь на Novikov On Soapbox. У нас нет рекламы
А, нет, всё-таки есть. Но вы всё равно подписывайтесь.
Такие дела
Такие дела
Усидеть на двух стульях
Недавно в твиттере был микро-скандал: доклад Антона Назарова о работе на двух работах одновременно пытались активно запретить и никому не давать запись. Мол, моральные устои разлагает.
Моральные устои, понимаете? Прикиньте, на каких соплях висит индустрия :) В общем, с моей колокольни ситуация тут довольно простая и я решил о ней высказаться.
Я считаю, что точить 100 сторипоинтов в день разработчик per se очень даже может. При наличии пула понятно сформулированных и правильно декомпозированных задач — легко. Отключаешь мозг и хреначишь код. Делов-то.
Но на практике сделать такой пул задач оказывается невозможно. Происходит это по разным причинам: изменчивость рынков, плавающие в широких диапазонах приоритеты, но чаще всего — левая пятка людей, стоящих выше рядовых разработчиков.
Давайте отбросим маски и сантименты: бэклоги в жопе по собственной же глупости и неорганизованности менеджеров и заказчиков.
Вместо того, чтобы прижать жопу к стулу и волевым решением организовать чёткую конвейерную работу по технической части, они создают 100500 созвонов, говорят "не важно как мы работаем, важно как мы общаемся", говорят "давайте согласуем эту задачу со всеми-всеми-всеми", говорят "мы собеседуем разработчиков по софт-скиллз". А любая коммуникация тормозит работу. И вот спустя какое-то время разработчик замечает, что благодаря такой системе организации до 50% времени разработка простаивает. Потому что разработчики ждут фидбека, ждут уточнения условий задачи, ждут билда, ждут когда из отпуска вернётся тот-самый-чел-апрува-от-которого-не-хватает. Мысль забить это время чем-то полезным приходит сама собой.
Кто-то просто отдыхает и прокрастинирует, кто-то занимается семьёй, кто-то пет-проектами. Ну а кто-то "вкручивает" в простои вторую работу. Что бы то ни было — оно впишется в то место в календаре, в котором проебался менеджмент. Всего то.
Что нужно понять менеджеру из этой заметки: попытка запретить доклад — это фуфломицин, который не лечит реальную проблему. Руководство IT уже в глубокой жопе. А значит, эффективность RnD тоже в жопе. Те самые "до 50% времени" разработчика уже уходит на непродуктивный хлам. Вашими же стараниями оно в любом случае будет продолбано. И тот факт, что разработчики эти 50% времени не мемчики скроллят, а пытаются заработать, вас никак не касается.
И нет, поставить тайм-трекер, принудить людей сидеть 8 часов — не поможет. Потому что причина в кривожопом планировании и дурной организации труда.
Такие дела
Недавно в твиттере был микро-скандал: доклад Антона Назарова о работе на двух работах одновременно пытались активно запретить и никому не давать запись. Мол, моральные устои разлагает.
Моральные устои, понимаете? Прикиньте, на каких соплях висит индустрия :) В общем, с моей колокольни ситуация тут довольно простая и я решил о ней высказаться.
Я считаю, что точить 100 сторипоинтов в день разработчик per se очень даже может. При наличии пула понятно сформулированных и правильно декомпозированных задач — легко. Отключаешь мозг и хреначишь код. Делов-то.
Но на практике сделать такой пул задач оказывается невозможно. Происходит это по разным причинам: изменчивость рынков, плавающие в широких диапазонах приоритеты, но чаще всего — левая пятка людей, стоящих выше рядовых разработчиков.
Давайте отбросим маски и сантименты: бэклоги в жопе по собственной же глупости и неорганизованности менеджеров и заказчиков.
Вместо того, чтобы прижать жопу к стулу и волевым решением организовать чёткую конвейерную работу по технической части, они создают 100500 созвонов, говорят "не важно как мы работаем, важно как мы общаемся", говорят "давайте согласуем эту задачу со всеми-всеми-всеми", говорят "мы собеседуем разработчиков по софт-скиллз". А любая коммуникация тормозит работу. И вот спустя какое-то время разработчик замечает, что благодаря такой системе организации до 50% времени разработка простаивает. Потому что разработчики ждут фидбека, ждут уточнения условий задачи, ждут билда, ждут когда из отпуска вернётся тот-самый-чел-апрува-от-которого-не-хватает. Мысль забить это время чем-то полезным приходит сама собой.
Кто-то просто отдыхает и прокрастинирует, кто-то занимается семьёй, кто-то пет-проектами. Ну а кто-то "вкручивает" в простои вторую работу. Что бы то ни было — оно впишется в то место в календаре, в котором проебался менеджмент. Всего то.
Что нужно понять менеджеру из этой заметки: попытка запретить доклад — это фуфломицин, который не лечит реальную проблему. Руководство IT уже в глубокой жопе. А значит, эффективность RnD тоже в жопе. Те самые "до 50% времени" разработчика уже уходит на непродуктивный хлам. Вашими же стараниями оно в любом случае будет продолбано. И тот факт, что разработчики эти 50% времени не мемчики скроллят, а пытаются заработать, вас никак не касается.
И нет, поставить тайм-трекер, принудить людей сидеть 8 часов — не поможет. Потому что причина в кривожопом планировании и дурной организации труда.
Такие дела
Рынок, который мы не замечаем
В мире есть огромный рынок, который мы по глупости или будучи в ежедневных запарах не замечаем.
Это — рынок людей, которые хотят оправдать своё существование. Я уверен, это один из мощнейших голубых океанов.
Инстаграм, твиттер, онлайн-курсы, книжные магазины — они успешны, потому что дают человеку площадку чтобы самореализоваться. И под этим словом я не подразумеваю какую-то пошлость вроде вот "фотографам надо фотать и показывать свой материал аудитории". А для удовлетворения своих амбиций. Чтобы чем-то оправдать своё зачастую довольно жалкое существование.
Без интернета Василий Петрович из Крыжополя — начинающий рыбак, любящий пропустить рюмочку под закуску из вяленого мяса. С интернетом — активный и счастливый одноклассник, постящий кучу фоток с охоты и получающий лайки "от Зинки из 8А, ну помнишь была такая?...". В худшем случае — видеоблогер, рассказывающий про лайфхаки выживальщика и даже как-то монетизирующийся.
Без интернета девушка Аглая из села Мышиные Потрошки была бы обычной дояркой. Но к счастью у Аглаи есть инстаграм. И там она — королева бала, постящая нафильтрованные фотки своего села в разных ракурсах, а так же селфи себя с таким романтичным осенним листиком. И вот уже не такая уж Аглая и доярка. В худшем случае Аглая — бьюти-блогер. В совсем худшем — OnlyFans, уж простите. В самом худшем — "девочки, записываемся на семинар по астральным медитациям на увеличение денежного потока!".
Без интернета молодой человек Арсений — самый обычный студент 2го курса ПТУ. У него нелады с личной жизнью, начинаются проблемы с алкоголем, вопросики к успеваемости и обрыдлые стены общаги по периметру. Но благодаря интернету, Арсений — профессиональный игрок в Доту, которого не раз звали на чемпионаты, а видосы с его катками — одни из самых просматриваемых на тематических ютуб-каналах. Или Арсений понимает, что ПТУ — это такоэ себе, крутить гайки на заводе ему неохота, поэтому вжух — и вот он уже слушатель онлайн-курса по PHP, а через полгода подыскивает первую шабашку в этом направлении. Или OnlyFans опять же (да, и такое бывает!). В самом худшем случае, стезя Арсения — это "внимание! взломана платформа бинарных опционов УшлыйБоров! я уже поднял 50к, в личку за подробностями".
Что-то мне подсказывает, что рынок благоволит продуктам, которые дают пользователю возможность самореализоваться всеми правдами и неправдами. Или хотя бы создать видимость самореализации.
И таких — сотни тысяч. Людей, которые жаждут чтобы интернет оправдал их существование.
Но это всё не точно, как вы понимаете :). Да и вообще кто я такой чтобы так визионировать. Пойду пиццы закажу. В интернете.
Такие дела
В мире есть огромный рынок, который мы по глупости или будучи в ежедневных запарах не замечаем.
Это — рынок людей, которые хотят оправдать своё существование. Я уверен, это один из мощнейших голубых океанов.
Инстаграм, твиттер, онлайн-курсы, книжные магазины — они успешны, потому что дают человеку площадку чтобы самореализоваться. И под этим словом я не подразумеваю какую-то пошлость вроде вот "фотографам надо фотать и показывать свой материал аудитории". А для удовлетворения своих амбиций. Чтобы чем-то оправдать своё зачастую довольно жалкое существование.
Без интернета Василий Петрович из Крыжополя — начинающий рыбак, любящий пропустить рюмочку под закуску из вяленого мяса. С интернетом — активный и счастливый одноклассник, постящий кучу фоток с охоты и получающий лайки "от Зинки из 8А, ну помнишь была такая?...". В худшем случае — видеоблогер, рассказывающий про лайфхаки выживальщика и даже как-то монетизирующийся.
Без интернета девушка Аглая из села Мышиные Потрошки была бы обычной дояркой. Но к счастью у Аглаи есть инстаграм. И там она — королева бала, постящая нафильтрованные фотки своего села в разных ракурсах, а так же селфи себя с таким романтичным осенним листиком. И вот уже не такая уж Аглая и доярка. В худшем случае Аглая — бьюти-блогер. В совсем худшем — OnlyFans, уж простите. В самом худшем — "девочки, записываемся на семинар по астральным медитациям на увеличение денежного потока!".
Без интернета молодой человек Арсений — самый обычный студент 2го курса ПТУ. У него нелады с личной жизнью, начинаются проблемы с алкоголем, вопросики к успеваемости и обрыдлые стены общаги по периметру. Но благодаря интернету, Арсений — профессиональный игрок в Доту, которого не раз звали на чемпионаты, а видосы с его катками — одни из самых просматриваемых на тематических ютуб-каналах. Или Арсений понимает, что ПТУ — это такоэ себе, крутить гайки на заводе ему неохота, поэтому вжух — и вот он уже слушатель онлайн-курса по PHP, а через полгода подыскивает первую шабашку в этом направлении. Или OnlyFans опять же (да, и такое бывает!). В самом худшем случае, стезя Арсения — это "внимание! взломана платформа бинарных опционов УшлыйБоров! я уже поднял 50к, в личку за подробностями".
Что-то мне подсказывает, что рынок благоволит продуктам, которые дают пользователю возможность самореализоваться всеми правдами и неправдами. Или хотя бы создать видимость самореализации.
И таких — сотни тысяч. Людей, которые жаждут чтобы интернет оправдал их существование.
Но это всё не точно, как вы понимаете :). Да и вообще кто я такой чтобы так визионировать. Пойду пиццы закажу. В интернете.
Такие дела
Грануляция
Думаю, это одно из самых важных слов на сегодняшний день в IT. Оно очень ёмкое, потому что покрывает целый пласт проблем. Давайте на примере.
Все же читали про такой антипаттерн как god object? Ну это когда внутри одного-единственного класса прячется небольших размеров галактика. Он содержит кучу методов (дай боже если часть из них — приватные) и несёт на себе кучу разных обязанностей. Проще говоря — делает всё. От бана пользователей до подсчёта зарплаты сотрудникам. От записи в базу до маппинга web DTO-шек на модельные сущности. Таким образом, любая сколь-нибудь важная фича этот класс использует.
Очевидно, это плохо. Почему? Потому что при любых багах в любой части системы в этот класс будут вносится изменения. Как результат — непрерывные мерж-конфликты, порождающие мерж-баги, приводящие к ещё бОльшим конфликтам... Ну ладно, это решается (только в C#) модиификатором partial. А вот с тем, что при разработке любой новой функциональности скорее всего этот блоб тоже будет задействован и изменён — с этим уже ничего не сделаешь. Б-г будет внутри каждой фичи. Если две или более фичи собираются, то б-г будет между ними. На него надлежит молиться и уповать. Судьбы мирские будут вершиться им... В общем за полным списком всех оказываемых эффектов, добро пожаловать в Новый Завет. Даром что god.
А вот другая крайность: в PHP/CGI минимальная единица кода — это .php-файл. В концепции CGI, http-демон по сути запускал php как отдельный процесс, скармливал ему в STDIN web-запрос, получал от него в STDOUT ответ, после чего процесс php убивался. И это работало не только с php, а вообще с любым языком, на котором вы могли написать консольное приложение. Хоть с C++. В FastCGI процессы ещё и пулились. И это было чертовски удобно, плюс работало достаточно быстро. А ещё позволяло передеплоить любой обработчик любого POST/GET запроса не трогая всю остальную систему.
Кто помнит FastCGI, тот над serverless не смеётся. Если идти на поводу у мысли DevOps-ориентированных архитектов и линуксоидов со стажем, то можно заметить, что все их чаяния сводятся к тому, чтобы воспроизвести логику FastCGI, только с помощью других технологий. Ну и плюс ещё чтобы каждый из запросов можно было отдельно лоад-балансить, что, кстати, по-своему удобно. Представьте если у вас будет микросервис-на-запрос. Представьте каких и скольо у вас будет Dockerfile-ов, репозиториев и деплой-пайплайнов. И как они будут друг с другом связаны. Ужаснитесь.
О чём оба два вышеперечисленных случая? Они — о грануляции.
Грануляция — это политика дробления систем на подсистемы (классы на подклассы, функции на отдельные процедуры), дающая понимание с каким разбиением нам жить комфортно, построенная с учётом плюсов и минусов.
А теперь к плохим новостям: никакого готового рецепта "как нам правильно гранулировать?" не существует. Ответы в духе "так, чтобы не дублировать код", "микросервис-на-источник данных", "а нам и с монолитом ок" — незрелые ответы не мужей, но мальчиков. Правильный ответ только один: зависит от ситуации.
Хорошо когда в компании есть архитектор. Основная обязанность архитектора с моей точки зрения — следить за грануляцией в системе и вовремя выпихивать системы в подсистемы в нужных местах. И важно чтобы архитект был ОДИН. "Коллективная архитектура" — это миф. Пять человек не могут принять решение.
Ну и вот ещё что скажу. По моим наблюдениям одно плюс-минус универсальное правило грануляции всё-таки есть: группируйте по логике. Т.е. хороший микросервис — это микросервис, который целиком и полностью реализует какой-либо User Flow. SRP же, ну! Тут есть хорошая метафора: если у нас лёг микросервис для кредитования и пользователь, пришедшый в банк временно не может получить кредит — это приемлемо. Но если у нас лёг микросервис для входной двери и никто не может зайти в банк — это пипец.
Впрочем, про дверь я ещё напишу отдельно.
Такие дела
Думаю, это одно из самых важных слов на сегодняшний день в IT. Оно очень ёмкое, потому что покрывает целый пласт проблем. Давайте на примере.
Все же читали про такой антипаттерн как god object? Ну это когда внутри одного-единственного класса прячется небольших размеров галактика. Он содержит кучу методов (дай боже если часть из них — приватные) и несёт на себе кучу разных обязанностей. Проще говоря — делает всё. От бана пользователей до подсчёта зарплаты сотрудникам. От записи в базу до маппинга web DTO-шек на модельные сущности. Таким образом, любая сколь-нибудь важная фича этот класс использует.
Очевидно, это плохо. Почему? Потому что при любых багах в любой части системы в этот класс будут вносится изменения. Как результат — непрерывные мерж-конфликты, порождающие мерж-баги, приводящие к ещё бОльшим конфликтам... Ну ладно, это решается (только в C#) модиификатором partial. А вот с тем, что при разработке любой новой функциональности скорее всего этот блоб тоже будет задействован и изменён — с этим уже ничего не сделаешь. Б-г будет внутри каждой фичи. Если две или более фичи собираются, то б-г будет между ними. На него надлежит молиться и уповать. Судьбы мирские будут вершиться им... В общем за полным списком всех оказываемых эффектов, добро пожаловать в Новый Завет. Даром что god.
А вот другая крайность: в PHP/CGI минимальная единица кода — это .php-файл. В концепции CGI, http-демон по сути запускал php как отдельный процесс, скармливал ему в STDIN web-запрос, получал от него в STDOUT ответ, после чего процесс php убивался. И это работало не только с php, а вообще с любым языком, на котором вы могли написать консольное приложение. Хоть с C++. В FastCGI процессы ещё и пулились. И это было чертовски удобно, плюс работало достаточно быстро. А ещё позволяло передеплоить любой обработчик любого POST/GET запроса не трогая всю остальную систему.
Кто помнит FastCGI, тот над serverless не смеётся. Если идти на поводу у мысли DevOps-ориентированных архитектов и линуксоидов со стажем, то можно заметить, что все их чаяния сводятся к тому, чтобы воспроизвести логику FastCGI, только с помощью других технологий. Ну и плюс ещё чтобы каждый из запросов можно было отдельно лоад-балансить, что, кстати, по-своему удобно. Представьте если у вас будет микросервис-на-запрос. Представьте каких и скольо у вас будет Dockerfile-ов, репозиториев и деплой-пайплайнов. И как они будут друг с другом связаны. Ужаснитесь.
О чём оба два вышеперечисленных случая? Они — о грануляции.
Грануляция — это политика дробления систем на подсистемы (классы на подклассы, функции на отдельные процедуры), дающая понимание с каким разбиением нам жить комфортно, построенная с учётом плюсов и минусов.
А теперь к плохим новостям: никакого готового рецепта "как нам правильно гранулировать?" не существует. Ответы в духе "так, чтобы не дублировать код", "микросервис-на-источник данных", "а нам и с монолитом ок" — незрелые ответы не мужей, но мальчиков. Правильный ответ только один: зависит от ситуации.
Хорошо когда в компании есть архитектор. Основная обязанность архитектора с моей точки зрения — следить за грануляцией в системе и вовремя выпихивать системы в подсистемы в нужных местах. И важно чтобы архитект был ОДИН. "Коллективная архитектура" — это миф. Пять человек не могут принять решение.
Ну и вот ещё что скажу. По моим наблюдениям одно плюс-минус универсальное правило грануляции всё-таки есть: группируйте по логике. Т.е. хороший микросервис — это микросервис, который целиком и полностью реализует какой-либо User Flow. SRP же, ну! Тут есть хорошая метафора: если у нас лёг микросервис для кредитования и пользователь, пришедшый в банк временно не может получить кредит — это приемлемо. Но если у нас лёг микросервис для входной двери и никто не может зайти в банк — это пипец.
Впрочем, про дверь я ещё напишу отдельно.
Такие дела
Пять людей не могут принять решение
Получил вдогонку предыдущему посту вопрос в личку: "а что значит что пять людей не могут принять решение?". Отличный вопрос, я считаю. Надо раскрыть его отдельным постом. Итак.
Когда люди собираются вместе и им надо принять решение как поступить, начинается психологический цирк с конями. Для примера: думаете все пятеро будут думать про интересы компании и качество продукта? Пхах, да как бы не так!
У кого-то ипотека не закрыта и ему боязно потерять рабочее место. Кто-то не был в отпуске 50 лет и скоро коней двинет на работе. Кто-то съездил на конференцию и вдохновился гугловым подходом. Кто-то начитался моего канала и вообще кругами бегает-орёт что индустрия мертва и всё надо сжечь пламенным огнём. Кто-то прочитал книжку Фаулера и хочет показать как хорошо он её усвоил. Кто-то просто хочет по-дольше отдохнуть и по-меньше поработать. Кто-то знает интересы начальника и хочет с помощью подхалимажа забраться на должность выше. Кому-то не хочется включать мозг и они озвучивают мнение "на отъебись", потому что ну на митинг же позвали, так? Что-то сказать надо.
Для каждого принимаемое решение может обернуться разными последствиями. И негативные последствия для себя лично каждый из пятерых желает минимизировать, что вполне естественно для любого человека, интеллектом чуть выше поросёночка. А спорят эти товарищи за свои интересы — дай боже. Клочки летят по закоулочкам! Итог такого заседания? Правильно.
Принимается не самое эффективное решение, а наименее дискомфортное для каждого участника.
Поэтому с решениями проще по-старинке. "Высказывайте свои аргументы, а решение примет ответственный, действующий в интересах бизнеса и знающий общую картину". Да, ответственное лицо находится под дамокловым мечом лично директора и будет приглашён на очень неприятный разговор в случае плохих результатов с исходом вплоть до увольнения или штрафа.
Тут, конечно, тоже всплывают старые-добрые проблемы "доступа к телу", но знаете что я скажу? Весьма часто жизнь такова, что ЛЮБОЕ принятое решение, даже если оно неправильное, будет лучше отсутствия какого-либо решения в принципе.
Такие дела
Получил вдогонку предыдущему посту вопрос в личку: "а что значит что пять людей не могут принять решение?". Отличный вопрос, я считаю. Надо раскрыть его отдельным постом. Итак.
Когда люди собираются вместе и им надо принять решение как поступить, начинается психологический цирк с конями. Для примера: думаете все пятеро будут думать про интересы компании и качество продукта? Пхах, да как бы не так!
У кого-то ипотека не закрыта и ему боязно потерять рабочее место. Кто-то не был в отпуске 50 лет и скоро коней двинет на работе. Кто-то съездил на конференцию и вдохновился гугловым подходом. Кто-то начитался моего канала и вообще кругами бегает-орёт что индустрия мертва и всё надо сжечь пламенным огнём. Кто-то прочитал книжку Фаулера и хочет показать как хорошо он её усвоил. Кто-то просто хочет по-дольше отдохнуть и по-меньше поработать. Кто-то знает интересы начальника и хочет с помощью подхалимажа забраться на должность выше. Кому-то не хочется включать мозг и они озвучивают мнение "на отъебись", потому что ну на митинг же позвали, так? Что-то сказать надо.
Для каждого принимаемое решение может обернуться разными последствиями. И негативные последствия для себя лично каждый из пятерых желает минимизировать, что вполне естественно для любого человека, интеллектом чуть выше поросёночка. А спорят эти товарищи за свои интересы — дай боже. Клочки летят по закоулочкам! Итог такого заседания? Правильно.
Принимается не самое эффективное решение, а наименее дискомфортное для каждого участника.
Поэтому с решениями проще по-старинке. "Высказывайте свои аргументы, а решение примет ответственный, действующий в интересах бизнеса и знающий общую картину". Да, ответственное лицо находится под дамокловым мечом лично директора и будет приглашён на очень неприятный разговор в случае плохих результатов с исходом вплоть до увольнения или штрафа.
Тут, конечно, тоже всплывают старые-добрые проблемы "доступа к телу", но знаете что я скажу? Весьма часто жизнь такова, что ЛЮБОЕ принятое решение, даже если оно неправильное, будет лучше отсутствия какого-либо решения в принципе.
Такие дела
The Pool Is Closed
Для того, чтобы научиться писать код спинным мозгом — его надо писать 10 тысяч часов кряду.
Ой и вот только не надо врать об ого-го какой мозговой составляющей в работе инженера-программиста. Ребят, ну... Ну вот как в общем-то у любого инженера на работе. Газовика, электрика... При том, инженера-наладчика, судя по тенденции "не пиши своё — возьми готовое". Только те всякие инженерные конструкции в лабе/на производстве собирают-запускают-обслуживают, а мы софт собираем-запускаем-обслуживаем. Ничего сверхъестественного. У нас даже проще — у нас иногда и дети справляются.
Программирование — это такое же ремесло как и, например, булки печь. Хороший и опытный пекарь, я уверен, не вдумывается в каждую выпекаемую булку. Он повторяет отработанные до автоматизма паттерны на автомате, не думая. Что называется, работает спинным мозгом.
Хороший токарь тоже над каждой гайкой уже не задумывается. Глаз-алмаз, вслепую точит. Хотя, казалось бы, тоже инженерия. Чертёжи там, стандарты, ГОСТы... В конце-то концов нужно выучить как станок работает и что его кнопки делают. Вот вы разберётесь в такой системе? Я — нет.
Профессиональные музыканты — тоже хороший пример. Это только поначалу все ваши квинтовые круги, интервалы, обращения, ступени, трезвучия, тональности кажутся неимоверно сложными. А вот если несколько лет на инструменте поиграть, то эта вся теория впечатывается в систему мышления и ты просто с этим живёшь. И гармонии хорошие для песен слышишь, и, если повезёт, то ноты читаешь как текст. Это я вам говорю как человек, окончивший 8 лет музыкальной школы по классу баяна.
Любого хорошего музыканта пни — он вам прям из головы на пальцах раскидает сольфеджио, и покажет куда и почему он разрешает аккорды, подберёт на слух вашу любимую песню и вообще расскажет много всего. Если, конечно, захочет. И я вам отвечаю, что мы все охренеем от того, что эти люди считают очевидным.
Мы уже давно выросли из 00х. Позади остались последние дивные возгласы: "Галя, да я не знаю чем он там занимается... сидит сутками в своём комплюктере и головы не подымает". Выстрелили у нас и свои Ford-ы с Chrysler-ами (FAANG), есть у нас и свои основы теоретической механики, и своё черчение тоже есть (чем исходный код концептуально отличается от чертежа?). Разработчики стали самыми обыкновенными инженерами. Младшими ли, старшими ли... Пуско-наладчиками ли, инженерами сопровождения. Механиками, сотрудниками ОТК. Кое-кто, конечно, попал и в отряд маляров-штукатуров, и уборщиков. Но мы сейчас о них не будем.
Одним словом — самое обычное производство. Только механизмы у нас разве что виртуальные. Глазом их не увидишь, не потрогаешь. Но это не беда. У нефтянников вон тоже бензин в нефти не потрогаешь, пока его не добудут — и ничего. В общем ребят, никакого волшебного и уникального IT нет. Наши отцы и деды инженерили на заводах, мы инженерим на галерах.
А давайте в твиттере флешмоб запустим! Пишите свою должность в резюме или в вакансии и как бы она называлась на производстве. Добавляйте хэштег #еслибыяработалназаводе.
Посмотрим, как говорится, сколько нас.
Такие дела
Для того, чтобы научиться писать код спинным мозгом — его надо писать 10 тысяч часов кряду.
Ой и вот только не надо врать об ого-го какой мозговой составляющей в работе инженера-программиста. Ребят, ну... Ну вот как в общем-то у любого инженера на работе. Газовика, электрика... При том, инженера-наладчика, судя по тенденции "не пиши своё — возьми готовое". Только те всякие инженерные конструкции в лабе/на производстве собирают-запускают-обслуживают, а мы софт собираем-запускаем-обслуживаем. Ничего сверхъестественного. У нас даже проще — у нас иногда и дети справляются.
Программирование — это такое же ремесло как и, например, булки печь. Хороший и опытный пекарь, я уверен, не вдумывается в каждую выпекаемую булку. Он повторяет отработанные до автоматизма паттерны на автомате, не думая. Что называется, работает спинным мозгом.
Хороший токарь тоже над каждой гайкой уже не задумывается. Глаз-алмаз, вслепую точит. Хотя, казалось бы, тоже инженерия. Чертёжи там, стандарты, ГОСТы... В конце-то концов нужно выучить как станок работает и что его кнопки делают. Вот вы разберётесь в такой системе? Я — нет.
Профессиональные музыканты — тоже хороший пример. Это только поначалу все ваши квинтовые круги, интервалы, обращения, ступени, трезвучия, тональности кажутся неимоверно сложными. А вот если несколько лет на инструменте поиграть, то эта вся теория впечатывается в систему мышления и ты просто с этим живёшь. И гармонии хорошие для песен слышишь, и, если повезёт, то ноты читаешь как текст. Это я вам говорю как человек, окончивший 8 лет музыкальной школы по классу баяна.
Любого хорошего музыканта пни — он вам прям из головы на пальцах раскидает сольфеджио, и покажет куда и почему он разрешает аккорды, подберёт на слух вашу любимую песню и вообще расскажет много всего. Если, конечно, захочет. И я вам отвечаю, что мы все охренеем от того, что эти люди считают очевидным.
Мы уже давно выросли из 00х. Позади остались последние дивные возгласы: "Галя, да я не знаю чем он там занимается... сидит сутками в своём комплюктере и головы не подымает". Выстрелили у нас и свои Ford-ы с Chrysler-ами (FAANG), есть у нас и свои основы теоретической механики, и своё черчение тоже есть (чем исходный код концептуально отличается от чертежа?). Разработчики стали самыми обыкновенными инженерами. Младшими ли, старшими ли... Пуско-наладчиками ли, инженерами сопровождения. Механиками, сотрудниками ОТК. Кое-кто, конечно, попал и в отряд маляров-штукатуров, и уборщиков. Но мы сейчас о них не будем.
Одним словом — самое обычное производство. Только механизмы у нас разве что виртуальные. Глазом их не увидишь, не потрогаешь. Но это не беда. У нефтянников вон тоже бензин в нефти не потрогаешь, пока его не добудут — и ничего. В общем ребят, никакого волшебного и уникального IT нет. Наши отцы и деды инженерили на заводах, мы инженерим на галерах.
А давайте в твиттере флешмоб запустим! Пишите свою должность в резюме или в вакансии и как бы она называлась на производстве. Добавляйте хэштег #еслибыяработалназаводе.
Посмотрим, как говорится, сколько нас.
Такие дела
Многофакторная аутентификация
Я испытываю фейспалм всякий раз, когда натыкаюсь на криво прописанную логику многофакторной аутентификации. Происходит это в самых разных продуктах: Яндекс, Альфа-Банк, Открытие, Кинопоиск. Меня это бесит, поэтому я давно хотел сделать обстоятельный пост мини-продуктового анализа вокруг многофакторной аутентификации. Вот он.
Что вообще такое "фактор аутентификации"? Вот смотрите, есть у нас пользователь Вася. Системе, которая предоставляет Васе персонифицированные услуги, нужно как-то быть уверенной что Вася — действительно тот, за кого себя выдаёт. Для этого Васе надо привести какие-то аргументы. Они и называются "факторы аутентификации". В современном мире кибератак и утечек данных, важно предоставить Васе как можно больше таких факторов. Поэтому и появилось MFA.
Базовым фактором аутентификации до сих пор остаётся логин и пароль. Он должен быть всегда. Даже если пользователь зашёл через "одноклассники", эти базовые установочные данные ему нужно сгенерировать. Тут есть некоторое пространство для манёвра: можно отправить сгенерированный пароль по потенциально скомпрометированному каналу данных (e-mail, SMS). Можно сгенерировать одноразовый пароль и заставить пользователя сменить его, что плохо скажется на UX, но хорошо скажется на безопасности.
Само собой на стороне бекенда пароли должны быть хэшированными и посоленными. Желательно несколько раз. Каждая новая соль в пароль усложняет жизнь злоумышленнику, решившему пойти по вектору атаки "спиздить данные". Если соли нет — достаточно стащить базу данных. Если соль задаётся в конфиге приложения — конфиг тоже придётся утащить. Если соль вшита в код, то придётся упереть ещё и исходники. Каждая следующая точка соления повышает цену всего вектора атаки, вынуждая злоумышленника в конце концов отказаться от этой идеи.
Но какие факторы есть помимо логина и пароля? Тут есть из чего выбрать:
— авторизация через OpenAPI соцсети
— по клиентскому сертификату
— одноразовый код, присланный по e-mail или телефон
— список одноразовых паролей
— ответы на секретные вопросы
— MFA через мобильное приложение Authenticator от Google/MS/whoever. Там внутри ГПСЧ, синхронизирующий seed с системой. Иногда такой Authenticator имеет аппаратный корпус и называется PIN-калькулятор. Странно что российские банки до этой идеи не додумались.
Прикольный фактор аутентификации был когда-то у Facebook: тебе показывали аватарки твоих друзей и предлагали ответить как кого зовут. Готовы осознать все грани собственной асоциальности? :)
Это далеко не полный список. У каждого фактора есть своя специфика работы, но выстраивая их систему надо уметь сделать правильные трейд-оффы между UX и безопасностью. Увы, это как раз тот случай когда одно исключает другое.
Пользователи могут тупо терять некоторые факторы аутентификации. SIM-карта может сломаться, пользователь может уехать в другой регион. Пароль можно забыть, друзей не иметь, e-mail удалит спам-фильтр, а телефон сменится на новенький-чистенький айфон, в котором нет приложения Authenticator. Потеря фактора адово просаживает UX и чем быстрее мы поможем пользователю восстановить доступ — тем лучше.
Но иногда факторы аутентификации крадут. Крадут пароли, братья и сёстры знают друзей, близкие знают ответы на секретные вопросы, e-mail могут угнать, телефон украсть, а SIM-карту скопировать. В этом случае, вор предъявит нам один из факторов и будет требовать пустить его. Чем раньше и жестче мы ему откажем — тем лучше. Парадокс!
Многофакторная аутентификация основывается на предположении, что все факторы одновременно не украдут и не потеряют. Но, как видите, вопрос довольно щепетильный и политику MFA надо калибровать индивидуально под каждую систему. Желательно, с диаграммами и картинками.
Такие дела
Я испытываю фейспалм всякий раз, когда натыкаюсь на криво прописанную логику многофакторной аутентификации. Происходит это в самых разных продуктах: Яндекс, Альфа-Банк, Открытие, Кинопоиск. Меня это бесит, поэтому я давно хотел сделать обстоятельный пост мини-продуктового анализа вокруг многофакторной аутентификации. Вот он.
Что вообще такое "фактор аутентификации"? Вот смотрите, есть у нас пользователь Вася. Системе, которая предоставляет Васе персонифицированные услуги, нужно как-то быть уверенной что Вася — действительно тот, за кого себя выдаёт. Для этого Васе надо привести какие-то аргументы. Они и называются "факторы аутентификации". В современном мире кибератак и утечек данных, важно предоставить Васе как можно больше таких факторов. Поэтому и появилось MFA.
Базовым фактором аутентификации до сих пор остаётся логин и пароль. Он должен быть всегда. Даже если пользователь зашёл через "одноклассники", эти базовые установочные данные ему нужно сгенерировать. Тут есть некоторое пространство для манёвра: можно отправить сгенерированный пароль по потенциально скомпрометированному каналу данных (e-mail, SMS). Можно сгенерировать одноразовый пароль и заставить пользователя сменить его, что плохо скажется на UX, но хорошо скажется на безопасности.
Само собой на стороне бекенда пароли должны быть хэшированными и посоленными. Желательно несколько раз. Каждая новая соль в пароль усложняет жизнь злоумышленнику, решившему пойти по вектору атаки "спиздить данные". Если соли нет — достаточно стащить базу данных. Если соль задаётся в конфиге приложения — конфиг тоже придётся утащить. Если соль вшита в код, то придётся упереть ещё и исходники. Каждая следующая точка соления повышает цену всего вектора атаки, вынуждая злоумышленника в конце концов отказаться от этой идеи.
Но какие факторы есть помимо логина и пароля? Тут есть из чего выбрать:
— авторизация через OpenAPI соцсети
— по клиентскому сертификату
— одноразовый код, присланный по e-mail или телефон
— список одноразовых паролей
— ответы на секретные вопросы
— MFA через мобильное приложение Authenticator от Google/MS/whoever. Там внутри ГПСЧ, синхронизирующий seed с системой. Иногда такой Authenticator имеет аппаратный корпус и называется PIN-калькулятор. Странно что российские банки до этой идеи не додумались.
Прикольный фактор аутентификации был когда-то у Facebook: тебе показывали аватарки твоих друзей и предлагали ответить как кого зовут. Готовы осознать все грани собственной асоциальности? :)
Это далеко не полный список. У каждого фактора есть своя специфика работы, но выстраивая их систему надо уметь сделать правильные трейд-оффы между UX и безопасностью. Увы, это как раз тот случай когда одно исключает другое.
Пользователи могут тупо терять некоторые факторы аутентификации. SIM-карта может сломаться, пользователь может уехать в другой регион. Пароль можно забыть, друзей не иметь, e-mail удалит спам-фильтр, а телефон сменится на новенький-чистенький айфон, в котором нет приложения Authenticator. Потеря фактора адово просаживает UX и чем быстрее мы поможем пользователю восстановить доступ — тем лучше.
Но иногда факторы аутентификации крадут. Крадут пароли, братья и сёстры знают друзей, близкие знают ответы на секретные вопросы, e-mail могут угнать, телефон украсть, а SIM-карту скопировать. В этом случае, вор предъявит нам один из факторов и будет требовать пустить его. Чем раньше и жестче мы ему откажем — тем лучше. Парадокс!
Многофакторная аутентификация основывается на предположении, что все факторы одновременно не украдут и не потеряют. Но, как видите, вопрос довольно щепетильный и политику MFA надо калибровать индивидуально под каждую систему. Желательно, с диаграммами и картинками.
Такие дела
Рынок, который мы не замечаем — 2
История взята из бизнес-кейса. В 2001 Джулиан Кук, выпустившись с MBA захотел сделать бизнес. А именно: авиакомпанию с двумя Boeing-737, переделанными целиком под бизнес-класс. 80 мест. Авиакомпания будет осуществлять регулярные рейсы из Лондона в Нью-Йорк, но билеты на них будут стоить не $5000, как обычный бизнес-класс, а всего $2500. Пассажирам будет предоставлена регистрация без очередей (интересно, как? если все летят бизнесом, то появится очередь на стойке регистрации... ай, проехали). Подвоз-отвоз от самолёта специальным транспортом, бизнес-лаунж со скидкой, душ в аэропортах прилёта-улёта, встреча с табличкой.
В общем короче. Это нечто ооочень похоже на бизнес-класс, но понимаете, не совсем бизнес. И не совсем класс, кекеке, потому что затея с треском провалилась. Там была куча нестыковок. Например, что выходить на 11-ти часовой перелёт всего с двумя самолётами и заявлять премиум-обслуживание — это, мягко говоря, отчаянный шаг. Например, что VIP, которое может себе позволить любой и за деньги — это уже не VIP. Например, не очень понятно на хер тут нужен душ в конце-то концов?! Но да ладно.
А главная причина провала кроется в том, что Джулиан не понял свою целевую аудиторию. Он по ошибке предположил, что у него будут летать деловые бизнесмены по своим деловым бизнесменским делам. А понимаете, того кто летит бизнес-классом Лондон — Нью-Йорк стоимость билета особо не колышет, я вам доложу. Его экономией 2.5 килобаксов не соблазнишь. А люди, которых реально интересовал такой прикольный "бизнес" за $2500 — это кто? Это, как ни странно, крепкие малые предприниматели, хорошо зарабатывающие фрилансеры, детки из просто состоятельных семей. И этих всех песонажей по состоянию на 2001 год было ничтожно мало. Джулиан впал в печаль.
Потом он всё же основал самую обычную авиакомпанию, которая позже была куплена Etihad, но это совсем другая история.
Но погодите, что я вижу?! В 2010 Антон Чиркунов влетает ровно в этот же рынок со своей совершенно прекрасной компанией Wheely. И у него, как ни странно, получается! Спустя 10 лет бизнес, бьющий в аналогичную ЦА, внезапно, перестаёт страдать от недостатка продаж и живёт себе спокойненько. Вот это, конечно, номер! Нет, ну то есть я не думаю что у Антона там лично какие-то сверхприбыли. Более того — я за него с радостью подниму бокал если у него в ноль всё сходится.
И коль оно так, то мы имеем с пылу с жару новенький "рынок". Беру "рынок" в кавычки чтобы маркетологи не вдарили мне за терминологию.
Это целевая аудитория "пост-подростков". Тех самых, которые "30 — это новые 20, только у тебя есть деньги". Вот айтишники разных мастей — характерные представители. Ну да, у них не миллионы карманы жгут, ну давайте признаем. Однако хоп-хоп, да 5 тыщ в ресторане посидеть найдётся. И винишко иногда хочется взять по-дороже, а не шмурдяк за 300 рублей. Того и глядишь, минибар дома соберут! Гаджет новый с зарплаты? Да легко. Ну не последний айфон, да. Но такой... приличный Samsung. И в отпуск полететь — ну не в Сочи конечно же. И не в Турцию-будурцию. На Гоа какой-нибудь, на о. Шри-Ланка. Того и гляди, засранцы, билет в бизнес-класс себе купят! Так, знаете... чисто попробовать.
Словом, они ещё не бизнес, но уже и не middle. И им очень хочется посмотреть хоть одним глазком что же там... на уровень выше? И я думаю, рынок им эту возможность предоставит.
Такие дела
История взята из бизнес-кейса. В 2001 Джулиан Кук, выпустившись с MBA захотел сделать бизнес. А именно: авиакомпанию с двумя Boeing-737, переделанными целиком под бизнес-класс. 80 мест. Авиакомпания будет осуществлять регулярные рейсы из Лондона в Нью-Йорк, но билеты на них будут стоить не $5000, как обычный бизнес-класс, а всего $2500. Пассажирам будет предоставлена регистрация без очередей (интересно, как? если все летят бизнесом, то появится очередь на стойке регистрации... ай, проехали). Подвоз-отвоз от самолёта специальным транспортом, бизнес-лаунж со скидкой, душ в аэропортах прилёта-улёта, встреча с табличкой.
В общем короче. Это нечто ооочень похоже на бизнес-класс, но понимаете, не совсем бизнес. И не совсем класс, кекеке, потому что затея с треском провалилась. Там была куча нестыковок. Например, что выходить на 11-ти часовой перелёт всего с двумя самолётами и заявлять премиум-обслуживание — это, мягко говоря, отчаянный шаг. Например, что VIP, которое может себе позволить любой и за деньги — это уже не VIP. Например, не очень понятно на хер тут нужен душ в конце-то концов?! Но да ладно.
А главная причина провала кроется в том, что Джулиан не понял свою целевую аудиторию. Он по ошибке предположил, что у него будут летать деловые бизнесмены по своим деловым бизнесменским делам. А понимаете, того кто летит бизнес-классом Лондон — Нью-Йорк стоимость билета особо не колышет, я вам доложу. Его экономией 2.5 килобаксов не соблазнишь. А люди, которых реально интересовал такой прикольный "бизнес" за $2500 — это кто? Это, как ни странно, крепкие малые предприниматели, хорошо зарабатывающие фрилансеры, детки из просто состоятельных семей. И этих всех песонажей по состоянию на 2001 год было ничтожно мало. Джулиан впал в печаль.
Потом он всё же основал самую обычную авиакомпанию, которая позже была куплена Etihad, но это совсем другая история.
Но погодите, что я вижу?! В 2010 Антон Чиркунов влетает ровно в этот же рынок со своей совершенно прекрасной компанией Wheely. И у него, как ни странно, получается! Спустя 10 лет бизнес, бьющий в аналогичную ЦА, внезапно, перестаёт страдать от недостатка продаж и живёт себе спокойненько. Вот это, конечно, номер! Нет, ну то есть я не думаю что у Антона там лично какие-то сверхприбыли. Более того — я за него с радостью подниму бокал если у него в ноль всё сходится.
И коль оно так, то мы имеем с пылу с жару новенький "рынок". Беру "рынок" в кавычки чтобы маркетологи не вдарили мне за терминологию.
Это целевая аудитория "пост-подростков". Тех самых, которые "30 — это новые 20, только у тебя есть деньги". Вот айтишники разных мастей — характерные представители. Ну да, у них не миллионы карманы жгут, ну давайте признаем. Однако хоп-хоп, да 5 тыщ в ресторане посидеть найдётся. И винишко иногда хочется взять по-дороже, а не шмурдяк за 300 рублей. Того и глядишь, минибар дома соберут! Гаджет новый с зарплаты? Да легко. Ну не последний айфон, да. Но такой... приличный Samsung. И в отпуск полететь — ну не в Сочи конечно же. И не в Турцию-будурцию. На Гоа какой-нибудь, на о. Шри-Ланка. Того и гляди, засранцы, билет в бизнес-класс себе купят! Так, знаете... чисто попробовать.
Словом, они ещё не бизнес, но уже и не middle. И им очень хочется посмотреть хоть одним глазком что же там... на уровень выше? И я думаю, рынок им эту возможность предоставит.
Такие дела
VIP-реквием
Был такой гэг в истории iOS, если кто помнит: приложение I Am Rich. Вкратце продуктовая история: чувак просто сделал приложение, которое отображает летающий по экрану рубин и текст в стиле "да, сучечки, я успешен". И выставил его в аппстор за максимально возможную цену: 999$. Ну то есть по задумке единственная функция этого приложения в том, чтобы показывать окружающим как ты крут. Прямым текстом.
Задумку не оценили. Приложение было куплено всего 8 раз, при том дважды — по ошибке. Apple подумала денёк, да и снесла приложение из стора. А добрые люди удостоили этот оригинальный случай post-mortem-а ажно на википедии. Дивно!
Так вот это я к чему? Несколько раз в жизни я сталкивался с ребятками, у которых на деловой активности двинулась кукуха. Они водятся на престижных факультетах престижных вузов и заняты тем, что носятся туда-сюда с гениальными бизнес-идеями, которые они быстро замутят и станут миллионерами.
Одна из наиболее частых фантазий на эту тему звучит так: "вот щас я как выпущусь, как сделаю какой-нибудь проект для премиум-сегмента за овермиллион бабок, а себестоимость будет копеешная". Что интересно, себестоимость действительно будет копеешная. Особенно если на должность администратора мега-VIP-SPA-комплекса нанять студента-второкурсника, совмещающего работу с грызением матана в общаге.
Только это будет не VIP-сервис, а какой-то голожопый деревенский театр, изображающий VIP-сервис. И интересен он будет в основном самому учредителю и его друзьям.
Никакого рынка VIP-услуг нет. Включите телевизор. Новости или передачу "парламентский час". Вот все ваши VIP, видите? Вот, в одном помещении собрались. Имена-фамилии-телефоны на сайте. Концерт ко дню милиции включите. Вон все ваши VIP-ы, на сцене для вас пляшут и поют. Или хотя бы КВН. Там три первых ряда этими вашими VIP-ами забиты до отказа. И контакты их можно при желании достать.
Идите, давайте, продайте им услугу премиум-уровня. В исполнении прыщавого студента, ага. Много напродаёте? Миллионеры, блин, из Балашихи.
Вокруг любого видного персонажа, располагающего большими деньгами действительно возникает крооохотный такой сегментик рынка оказания индивидуальных услуг этому самому VIP-у. В конце концов им же есть что-то надо! Но вот беда: как только этот сегмент возникает, в него моментально набегает куча желающих кормить-мыть-брить-стирать. И всё это по знакомству в узких кругах, в которые миллионеров из Балашихи не пускают просто потому что чужим не доверяют.
Возможность подобраться к VIP-ам стандартными средствами маркетинга и продаж появляется где-то с уровня, мне кажется, типичного малого предпринимателя. Или муниципального депутата. А "муниципальный депутат" хоть и звучит грозно, да вот только денег там нет. Ни на какой VIP там уже раскошеливаться в массе своей не готовы. Но вполне могут пару раз купить себе тот самый голожопый деревенский театр. Просто посмотреть как оно.
И если оно кринжово и фальшиво (как обычно и бывает у бизнес-мальчиков), то на этом, тащемта, шапито и завершит операционную деятельность.
Такие дела
Был такой гэг в истории iOS, если кто помнит: приложение I Am Rich. Вкратце продуктовая история: чувак просто сделал приложение, которое отображает летающий по экрану рубин и текст в стиле "да, сучечки, я успешен". И выставил его в аппстор за максимально возможную цену: 999$. Ну то есть по задумке единственная функция этого приложения в том, чтобы показывать окружающим как ты крут. Прямым текстом.
Задумку не оценили. Приложение было куплено всего 8 раз, при том дважды — по ошибке. Apple подумала денёк, да и снесла приложение из стора. А добрые люди удостоили этот оригинальный случай post-mortem-а ажно на википедии. Дивно!
Так вот это я к чему? Несколько раз в жизни я сталкивался с ребятками, у которых на деловой активности двинулась кукуха. Они водятся на престижных факультетах престижных вузов и заняты тем, что носятся туда-сюда с гениальными бизнес-идеями, которые они быстро замутят и станут миллионерами.
Одна из наиболее частых фантазий на эту тему звучит так: "вот щас я как выпущусь, как сделаю какой-нибудь проект для премиум-сегмента за овермиллион бабок, а себестоимость будет копеешная". Что интересно, себестоимость действительно будет копеешная. Особенно если на должность администратора мега-VIP-SPA-комплекса нанять студента-второкурсника, совмещающего работу с грызением матана в общаге.
Только это будет не VIP-сервис, а какой-то голожопый деревенский театр, изображающий VIP-сервис. И интересен он будет в основном самому учредителю и его друзьям.
Никакого рынка VIP-услуг нет. Включите телевизор. Новости или передачу "парламентский час". Вот все ваши VIP, видите? Вот, в одном помещении собрались. Имена-фамилии-телефоны на сайте. Концерт ко дню милиции включите. Вон все ваши VIP-ы, на сцене для вас пляшут и поют. Или хотя бы КВН. Там три первых ряда этими вашими VIP-ами забиты до отказа. И контакты их можно при желании достать.
Идите, давайте, продайте им услугу премиум-уровня. В исполнении прыщавого студента, ага. Много напродаёте? Миллионеры, блин, из Балашихи.
Вокруг любого видного персонажа, располагающего большими деньгами действительно возникает крооохотный такой сегментик рынка оказания индивидуальных услуг этому самому VIP-у. В конце концов им же есть что-то надо! Но вот беда: как только этот сегмент возникает, в него моментально набегает куча желающих кормить-мыть-брить-стирать. И всё это по знакомству в узких кругах, в которые миллионеров из Балашихи не пускают просто потому что чужим не доверяют.
Возможность подобраться к VIP-ам стандартными средствами маркетинга и продаж появляется где-то с уровня, мне кажется, типичного малого предпринимателя. Или муниципального депутата. А "муниципальный депутат" хоть и звучит грозно, да вот только денег там нет. Ни на какой VIP там уже раскошеливаться в массе своей не готовы. Но вполне могут пару раз купить себе тот самый голожопый деревенский театр. Просто посмотреть как оно.
И если оно кринжово и фальшиво (как обычно и бывает у бизнес-мальчиков), то на этом, тащемта, шапито и завершит операционную деятельность.
Такие дела
Маркетологи
Вот уж где точно филиал ада на земле — так это в маркетинге.
Тут важно не путать. Есть продажники, которые кидаются на клиента, расплёскивая мёд из уст и уламывают его подписать контракт на услуги или поставки всеми правдами и неправдами. Но рынка они по сути не касаются. Их задача — впарить. То есть чтобы пришедший на порог клиент не ушёл без товара. Но вот если клиент не пришёл, то их полномочия всё. Сидят, в потолок плюют.
А вот привести клиента — это вам не в тапки срать. Тут целая наука. И имя ей — маркетинг. Если я правильно врубаюсь, то маркетинг представляет собой набор методик для исследования рынка (read) и изменения его состояния (write) путём вывода и продвижения новых продуктов. Позиционирование, брендинг, стратегии реализации — это всё тоже сюда, но философия маркетологов куда глубже. Первая строчка их библии гласит: "вначале был клиент. и клиент сформировал рынок". Утверждение это оказалось годным во всех смыслах настолько, что в 2021 сложно найти бизнес, который не построен от маркетинга. По идее это должно означать, что клиента ставят вперёд всех операционных процессов, но пока не суть.
Одно в маркетинге неудобно. Эта байда лезет буквально в каждое звено производственной цепочки. Ну типа "а давайте мы эту кнопку в жёлтый покрасим!". Спрашиваешь, зачем? "— А чтобы увеличить охват аудитории или добавить позитивный импринт". У товаров это выражается в дрочеве упаковки, а у программного обеспечения в дрочеве UI. Или, например, хотят маркетологи подкрутить доставку чтобы лучше продавалось. И что с ними делать? Неудобно, да. Но прибыли же обещают...
Когда же дело доходит до исследования рынков, то тут маркетинг прям расчехляется. Метрики! Больше метрик богу метрик! Благо, циферок в маркетинге довольно много, считать их можно бесконечно. Численность потенциальной целевой аудитории, количество кликов и переходов, ERR, DAU/MAU, retention, churn. Можно строить линии трендов, предсказательные модели, а там и бигдату, глядишь, подвезут.
Как вы поняли, маркетинг требует, выразимся так, весьма специфических знаний и навыков. Маркетолога я бы описал так: одухотворённый миллениал, держащий руку на пульсе рынка, но имеющий наготове 100500 данных, готовых подтвердить или опровергнуть любую гипотезу. Вечно генерит какие-то дикие хитрые планы, в основном касающиеся продвижения и позиционирования. Очень обижается если его не понимают. Маркетологу необходима крепкая рука начальника, которая вовремя будет возвращать его из креативного полёта обратно на грешну землю и пресекать неуместную математическую интеллектуализацию точным отеческим пиздюлём.
Если RnD в компании можно сравнить с тихим-уютным стойлом, в котором не спеша пасутся коты и тихонько в уголке варится продукт, то маркетинг — это астральный мир инсайтов, бесконечной креативности, позиционирования и метрик. Там удерживают внимание клиента, продвигают ценности и формируют позитивные образы, увеличивающие конверсию.
К чему я вам это, собственно, рассказываю? А чтобы показать насколько разработка и маркетинг — разные вещи.
Если вы — рядовой разработчик, а ваш начальник или PM имеет опыт работы в маркетинге — бегите, глупцы!
Маркетинг — это печать на всю жизнь. Человек из маркетинга, руководящий разработкой будет тратить тонну времени на дрочево клиентской части, игнорируя логику продукта. А самих разработчиков обложит глупыми метриками.
Такие дела
P.S: Кто сказал Агапитов?
Вот уж где точно филиал ада на земле — так это в маркетинге.
Тут важно не путать. Есть продажники, которые кидаются на клиента, расплёскивая мёд из уст и уламывают его подписать контракт на услуги или поставки всеми правдами и неправдами. Но рынка они по сути не касаются. Их задача — впарить. То есть чтобы пришедший на порог клиент не ушёл без товара. Но вот если клиент не пришёл, то их полномочия всё. Сидят, в потолок плюют.
А вот привести клиента — это вам не в тапки срать. Тут целая наука. И имя ей — маркетинг. Если я правильно врубаюсь, то маркетинг представляет собой набор методик для исследования рынка (read) и изменения его состояния (write) путём вывода и продвижения новых продуктов. Позиционирование, брендинг, стратегии реализации — это всё тоже сюда, но философия маркетологов куда глубже. Первая строчка их библии гласит: "вначале был клиент. и клиент сформировал рынок". Утверждение это оказалось годным во всех смыслах настолько, что в 2021 сложно найти бизнес, который не построен от маркетинга. По идее это должно означать, что клиента ставят вперёд всех операционных процессов, но пока не суть.
Одно в маркетинге неудобно. Эта байда лезет буквально в каждое звено производственной цепочки. Ну типа "а давайте мы эту кнопку в жёлтый покрасим!". Спрашиваешь, зачем? "— А чтобы увеличить охват аудитории или добавить позитивный импринт". У товаров это выражается в дрочеве упаковки, а у программного обеспечения в дрочеве UI. Или, например, хотят маркетологи подкрутить доставку чтобы лучше продавалось. И что с ними делать? Неудобно, да. Но прибыли же обещают...
Когда же дело доходит до исследования рынков, то тут маркетинг прям расчехляется. Метрики! Больше метрик богу метрик! Благо, циферок в маркетинге довольно много, считать их можно бесконечно. Численность потенциальной целевой аудитории, количество кликов и переходов, ERR, DAU/MAU, retention, churn. Можно строить линии трендов, предсказательные модели, а там и бигдату, глядишь, подвезут.
Как вы поняли, маркетинг требует, выразимся так, весьма специфических знаний и навыков. Маркетолога я бы описал так: одухотворённый миллениал, держащий руку на пульсе рынка, но имеющий наготове 100500 данных, готовых подтвердить или опровергнуть любую гипотезу. Вечно генерит какие-то дикие хитрые планы, в основном касающиеся продвижения и позиционирования. Очень обижается если его не понимают. Маркетологу необходима крепкая рука начальника, которая вовремя будет возвращать его из креативного полёта обратно на грешну землю и пресекать неуместную математическую интеллектуализацию точным отеческим пиздюлём.
Если RnD в компании можно сравнить с тихим-уютным стойлом, в котором не спеша пасутся коты и тихонько в уголке варится продукт, то маркетинг — это астральный мир инсайтов, бесконечной креативности, позиционирования и метрик. Там удерживают внимание клиента, продвигают ценности и формируют позитивные образы, увеличивающие конверсию.
К чему я вам это, собственно, рассказываю? А чтобы показать насколько разработка и маркетинг — разные вещи.
Если вы — рядовой разработчик, а ваш начальник или PM имеет опыт работы в маркетинге — бегите, глупцы!
Маркетинг — это печать на всю жизнь. Человек из маркетинга, руководящий разработкой будет тратить тонну времени на дрочево клиентской части, игнорируя логику продукта. А самих разработчиков обложит глупыми метриками.
Такие дела
P.S: Кто сказал Агапитов?
Forwarded from Pavlo Pedenko (Pavlo Pedenko)
История про сервисы доставки еды, сжигание денег и метрики.
Коллега работал в одном из таких проектов продактом и их сервис доставки еды был таким же безумно убыточным, как и большинство остальных (посмотрите репорты Uber Eats).
Так что рост надо было показывать, чтобы не остаться без следующего раунда, да и вообще не злить инвесторов лишний раз.
Поэтому, чтобы показывать рост заказов и понижение churn'a, ребята заказывали доставку банки кока-колы клиентам, которые "вот-вот отпадут" или "пришли после акции, и в целом у них слабый интент". Разумеется, клиент об этом не знал - заказ инициировался со стороны сервиса. Часто курьер приезжал к двери и заказ никто не принимал.
Все потому, что привезти бесплатную банку кока-колы гораздо дешевле, чем привлечь нового клиента. Разумеется, клиент не станет лояльнее в реальности, но на бумаге он останется активным.
Коллега работал в одном из таких проектов продактом и их сервис доставки еды был таким же безумно убыточным, как и большинство остальных (посмотрите репорты Uber Eats).
Так что рост надо было показывать, чтобы не остаться без следующего раунда, да и вообще не злить инвесторов лишний раз.
Поэтому, чтобы показывать рост заказов и понижение churn'a, ребята заказывали доставку банки кока-колы клиентам, которые "вот-вот отпадут" или "пришли после акции, и в целом у них слабый интент". Разумеется, клиент об этом не знал - заказ инициировался со стороны сервиса. Часто курьер приезжал к двери и заказ никто не принимал.
Все потому, что привезти бесплатную банку кока-колы гораздо дешевле, чем привлечь нового клиента. Разумеется, клиент не станет лояльнее в реальности, но на бумаге он останется активным.
Tи-шейп
Так получилось, что лично я близок к концепции "программисту должно быть пофигу на каком языке писать". Мне просто по стечению разных обстоятельств и разных рабочих мест приходилось смотреть всякое. И с PHP на C# портировал, и деплойментный yaml ковырял, и легаси на жаваскрипте трогал, и студенческие наработки на Java правил, и на C++ в универе писал (с тех пор, кстати, неплохо понимаю его логику), и go палочкой тыкал.
Горжусь ли я этим? Да на самом деле нет. Эти знания для меня — просто лишний головняк, который призван донести одну простую мысль: разобраться можно в чём угодно. Было бы время и давали бы деньги.
В остальном императивные языки плюс-минус одинаковы. А хаскелли на хер никому не нужны. Тут выпендривайся-не выпендривайся, а CPU всё же императивный, да оперативная память с линейной адресацией, и от устройств по-прежнему приходят прерывания. От этих обстоятельств не спрячешься ни за толстым слоем объектов, ни за монадами.
И я считаю что любой нормальный сениор — он ну где-то столько примерно и знает. А всех прочих я бы даже и на порог собеса не пустил.
Вот тут стоп! А теперь я снимаю шляпу софтвер-инженера и надеваю шляпу CTO.
Для любого проекта сколь угодно большой сложности мне нужны специалисты. При том мозговая сила команды должна быть как можно бОльшая. Следовательно, лучше брать отдельных людей на отдельные направления.
Мне нужен фронтендер. Хороший фронтендер, который будет знать на зубок все подкапотные хаки браузера, чтобы продукт, который я делаю был отточен и соптимизирован. Чтобы у нас не случалось дебильных UI-глитчей или тормозов. Я хочу, чтобы пользователи изнемогали от желания лизнуть наш фронтенд.
Мне нужен разраб на бек. И я, чёрт побери, хочу чтобы он провёл 10000 часов выдрачивая многопоточность, асинки и методики работы с СУБД и прочими хранилищами. Чтобы этот чувак шарил за паттерны проектирования, бизнес-логику и скейлинг нагрузки как б-женька. И чтоб руки были код печатать.
Если мы хотим сделать прям хорошо, то нужен спец по базам данных. Чувак, который знает все тонкости настройки, знает где там что можно подкрутить, сколько данных влезет и как база ведёт себя когда данные не влезают. Чтобы хорошо знал и умел SQL-профайлинг и дедлоки видел за километр. И индексы повреждённые умел восстанавливать.
Мне нужен не девопс, а девопсище. Чтобы кубернетис мог мне запинать, да политики доступа на прод-машинах настроить так, чтоб муха не пролетела. И чтобы при необходимости обжал сетевой кабель зубами. Всякое бывает.
Ну и так далее. Для успешной реализации систем мне нужна команда с опытом и знаниями. Тогда получится сделать так, чтобы потом не пришлось переделывать. А все инфантильные T-шейпнутые генералисты, часами обсуждающие какой язык программирования самый крутой, мне нахуй не нужны. Знания у команды будут откровенно хиленькие, зато в офисе тебя по всем вопросам мира проконсультируют... собсно, а нахера? Это — хорошие вводные не для команды инженеров, а для пятничного пивного клуба старых друзей.
Таких друзей — за хуй, как говорится, да в музей.
Такие дела
Так получилось, что лично я близок к концепции "программисту должно быть пофигу на каком языке писать". Мне просто по стечению разных обстоятельств и разных рабочих мест приходилось смотреть всякое. И с PHP на C# портировал, и деплойментный yaml ковырял, и легаси на жаваскрипте трогал, и студенческие наработки на Java правил, и на C++ в универе писал (с тех пор, кстати, неплохо понимаю его логику), и go палочкой тыкал.
Горжусь ли я этим? Да на самом деле нет. Эти знания для меня — просто лишний головняк, который призван донести одну простую мысль: разобраться можно в чём угодно. Было бы время и давали бы деньги.
В остальном императивные языки плюс-минус одинаковы. А хаскелли на хер никому не нужны. Тут выпендривайся-не выпендривайся, а CPU всё же императивный, да оперативная память с линейной адресацией, и от устройств по-прежнему приходят прерывания. От этих обстоятельств не спрячешься ни за толстым слоем объектов, ни за монадами.
И я считаю что любой нормальный сениор — он ну где-то столько примерно и знает. А всех прочих я бы даже и на порог собеса не пустил.
Вот тут стоп! А теперь я снимаю шляпу софтвер-инженера и надеваю шляпу CTO.
Для любого проекта сколь угодно большой сложности мне нужны специалисты. При том мозговая сила команды должна быть как можно бОльшая. Следовательно, лучше брать отдельных людей на отдельные направления.
Мне нужен фронтендер. Хороший фронтендер, который будет знать на зубок все подкапотные хаки браузера, чтобы продукт, который я делаю был отточен и соптимизирован. Чтобы у нас не случалось дебильных UI-глитчей или тормозов. Я хочу, чтобы пользователи изнемогали от желания лизнуть наш фронтенд.
Мне нужен разраб на бек. И я, чёрт побери, хочу чтобы он провёл 10000 часов выдрачивая многопоточность, асинки и методики работы с СУБД и прочими хранилищами. Чтобы этот чувак шарил за паттерны проектирования, бизнес-логику и скейлинг нагрузки как б-женька. И чтоб руки были код печатать.
Если мы хотим сделать прям хорошо, то нужен спец по базам данных. Чувак, который знает все тонкости настройки, знает где там что можно подкрутить, сколько данных влезет и как база ведёт себя когда данные не влезают. Чтобы хорошо знал и умел SQL-профайлинг и дедлоки видел за километр. И индексы повреждённые умел восстанавливать.
Мне нужен не девопс, а девопсище. Чтобы кубернетис мог мне запинать, да политики доступа на прод-машинах настроить так, чтоб муха не пролетела. И чтобы при необходимости обжал сетевой кабель зубами. Всякое бывает.
Ну и так далее. Для успешной реализации систем мне нужна команда с опытом и знаниями. Тогда получится сделать так, чтобы потом не пришлось переделывать. А все инфантильные T-шейпнутые генералисты, часами обсуждающие какой язык программирования самый крутой, мне нахуй не нужны. Знания у команды будут откровенно хиленькие, зато в офисе тебя по всем вопросам мира проконсультируют... собсно, а нахера? Это — хорошие вводные не для команды инженеров, а для пятничного пивного клуба старых друзей.
Таких друзей — за хуй, как говорится, да в музей.
Такие дела