5 января в 13:59

Управление → Из девопсов в стартаперы: два года до AppStore. Часть 1. Введение



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

Термин “девопс” мне на самом деле не нравится, хотя в современной терминологии это самое близкое (но далеко не исчерпывающее) описание круга работ, которые я выполнял более десяти лет на своем последнем месте работы. Какие-то области я изучал достаточно глубоко, какие-то поверхностно, но на протяжении всей своей 20-летней карьеры в IT я постоянно сталкивался с одной странной особенностью, которую решил назвать «культ ненужных знаний». Сразу предупрежу, что это моё сугубо лично мнение, которое я не собираюсь никому навязывать, но я вынужден начать свой цикл статей именно с этого, дабы впоследствии была понятна логика моих на первый взгляд «неправильных» (с технической или с любой другой точки зрения) решений.

Будучи в самом начале своего трудового пути я не мог не заметить, что в каждой области IT есть своя микрорелигия, в лучшем случае пропагандирующая определённый образ мышления, а в худшем — требующая знания кучи специальных терминов и навязывающая некие правила, указывающие на то, что «правильно», а что нет. Причём многие термины либо придуманы специально для этой области, либо имеют в ней специфический смысл, радикально отличающийся от смысла этого термина как в человеческом языке, так и в других областях IT. Чтобы было понятней, о чём я говорю, вспомните количество значений терминов «domain» и «node» в разных областях IT. Соглашусь, что в некоторых случаях (например, в языках программирования или хорошо продуманных фрэймворках) это кажется логичным и выглядит органично. Однако во многих случаях (например, учетные системы, CMS типа «Битрикс» и т.д.) обилие незнакомых и порой нелогичных терминов и правил у человека со стороны вызывают взрыв мозга и зачастую неоправданное чувство собственной неполноценности.

Впервые я заподозрил, что нечисто что-то в Датском королевстве, когда для каждого филиала независимо от его размера (сейчас и в дальнейшем в этой статье при упоминании предприятия я буду иметь в виду моё последнее место работы в качестве наёмного сотрудника) наш человек, который отвечал за IT-инфраструктуру в плане железа, OS и связи, устанавливал минимум по три Windows-сервера (и это без избыточности для надёжности). Я не могу описать технические подробности, т.к. не являюсь специалистом по Active Directory, но это как-то было связано с правилами организации леса и репликации в Active Directory. В том, что всё соответствовало правилам Майкрософт, у меня сомнений нет, т.к. он закончил курсы Microsoft для сисадминов. Да и я потом на каком-то семинаре у майкрософтовцев уточнял, правильно ли мы всё сделали. В итоге, для организации даже одного рабочего места требовалось наличие минимум трёх компьютеров с Windows Server. Возможно, что сейчас всё проще, но в 2003 году это было так.

Прозрение же относительно подобных «правил» в целом и Microsoft в частности у меня наступило несколько лет спустя, когда в ответ на просьбу опубликовать в сторе мой add-on для Экселя я получил письмо от сотрудника Microsoft с обратным адресом типа «loram@microsoft.com». Выходит, жили мы себе спокойно с корпоративными адресами типа IvanK@фирма.com, потом на курсах Майкрософт нам рассказала, что у нас всё неправильно, и мы всё переделали, как они научили. Сделали корневой домен «фирма.com», у него поддомены «город.фирма.com», а в них адреса формата «Имя.Фамилия@город.фирма.com». Сколько же у нас всё плевались и матерились на такие длинные адреса, но, типа, раз правильно так, значит надо так. Ну а Майкрософту, как оказалось, не обязательно свои же правила соблюдать. И, если раньше, когда я в угоду скорости, оптимизации или даже нежелания долго возиться тупо вбивал «костыль», нарушая какие-то догмы и парадигмы, меня не покидало чувство какой-то собственной неполноценности и даже, в некотором смысле, мучила совесть, то теперь подобный внутренний конфликт стал возникать гораздо реже. В дальнейшем моя вольность в интерпретации правил (как внутренних, так и общепринятых в каком-то языке или области) часто была причиной споров с коллегами, которые крайне негативно относились к подобным «костылям». Но бизнес есть бизнес, и если мои костыли ему помогали, то назвать меня полностью неправым было нельзя. Часто в результате этих споров хотелось ещё раз рассказать анекдот про верблюда в зоопарке:

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

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

Дальше я начал замечать похожую ситуацию и в других, отличных от IT областях. В финансах, парфюмерии, косметике, учетных системах и даже на курсах по английскому для преподавателей – везде были свои микропсевдонауки разной степени проработки и зрелости, надувание щёк людьми, изучившими эти псевдонауки, а также платное обучение и сертификация. В некоторых случаях ситуация была ещё неочевидней и хитрее. Например, известный производитель парфюмерии под предлогом конкурса организовывает обучение и сертификацию в Париже лучшему продавцу месяца/квартала/года. Естественно, продавцы и консультанты забывают о существовании других брендов как за месяц до конкурса, так и ещё на пару месяцев после (хочется ведь пощеголять новыми знаниями). А иногда эта ситуация принимает ещё более уродливую форму: когда наличие сертификата обучения каким-нибудь банальностям становится либо обязательным, либо крайне желательным. Напомню, сейчас я говорю не только об IT. Например, есть какой-то международный сертификат для преподавателей английского, где один из тестовых вопросов звучит примерно так: «Вы просите ученика достать линейку из портфеля и произнести её название на английском. Как называется это действие?». То есть они придумали свой термин даже для этого!

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

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

Я понимал, что всему этому есть какое-то логичное объяснение, но формализовать это не мог. И тут на помощь пришла музыка и расставила всё на свои места. Есть классическая музыка, исполняемая симфоническим оркестром. Тут присутствуют архитектор (композитор), ПМ (дирижер), подробное техзадание (партитуры). А есть рок-руппа, которая создает и играет музыку совсем по-другому. Можете себе представить Браяна Мэя, требующего от Фредди Меркьюри ноты для исполнения «Богемной Рапсодии»? В рок-группе все понимают друг друга с полуслова и вносят в исполнение свой вклад за счёт мастерства и таланта. В итоге, я пришел к выводу, что есть три подхода с разными правилами — оркестр, рок-группа и джазмен. Если я буду делать какой-нибудь фрэймворк или сложный продукт с сотней программистов, то я вынужден буду работать по правилам симфонического оркестра. Для стартапа с несколькими людьми достаточно быть сыгранной рок-группой, но с суперталантливыми музыкантами. Ну а одиночке-саксофонисту ничто не мешает уйти в полную импровизацию и делать всё так, как удобно лично ему и в угоду скорейшего выпуска готового продукта. Другой вопрос, что импровизировать без абсолютного музыкального слуха невозможно – будет полная лажа, но у меня вроде он (в виде многолетнего опыта и профессионального «чутья», где можно вбить костыль, а где лучше сделать системное решение) есть. На этом я успокоился, выбрал ради гибкости и скорости принятия решений вариант «джазмен» и начал работу над продуктом. Как я выбирал какой продукт и под какие платформы делать, какой инструментарий использовать, в какие тупики заходил, – читайте в следующих статьях, а пока что можно оценить результат — itunes.apple.com/ru/app/offlajn-brauzer-megalenta/id1013837150.
Автор: @Tiulkin
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Комментарии (6)

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

    Если что-то кажется вам слишком сложным, это вовсе не проявление «культа ненужных знаний». Если за 20 лет работы в индустрии вы не можете или не хотите один раз прочитать и понять до конца статью вроде Finding a Domain Controller in the Closest Site чтобы аргументированно дискутировать на тему «сколько и каких серверов надо на одну локацию» — это печально.
    • 0
      Не совсем понял что вы хотели сказать этим комментарием. То, что три windows-сервера для одного рабочего места – это всё-таки логично, или что «нельзя, но если очень хочется, то можно» со простыми адресами – это тоже «ок»? И, кстати, технологию не дают, а продают за хорошие деньги. Это, заметьте, две большие разницы. Также ничего печального не вижу в том, что я не прочитал ещё одну статью про ещё одну технологию, которую я не планирую использовать.
      • 0
        Лишь к тому, что длинное размышление о «культе», «излишестве» очень далеко от жизни. Культ излишних знаний простым человеческим языком называется «экспертиза». В каждой экспертизе есть своя терминология. В ИТ своя, в медицине, в логистике своя. При определенных условиях экспертиза очень дорого стоит. Непонимание терминологии не делает ее излишней.

        В плане конретного применения технологий вы можете сделать так, как вам больше подходит, исходя из ваших задач. Вендор может написать о каких-то совсем вырожденных случаях, что и так можно, но вот будут нюансы, и лучше бы воздержаться. Примером для AD могут быть single label domain names.

        Возможно, вам представляется чем-то хорошим, что вы не тратите время на то, чтобы хотя бы в общем понять смежные технологии. Вы видите себя Шерлоком Холмсом с идеально чистым чердаком. Но есть для этого и более простой термин — зашоренность. Лошадка должна бежать вперед, не надо отвлекаться на пролетающий пейзаж. Хорошо ли это? Спросите у кучера.

        Технологии есть разные, в общем и целом их, бесспорно, продают. Но кое-что, как у Шекли, вы можете получить и задаром.
        • 0
          Уж как-то очень быстро вы перешли на личности, навесили на меня ярлык и начали осуждать согласно этого ярлыка. Поверьте, я в состоянии освоить практически любую технологию в достаточно короткий срок (и освоил множество), и доказательство этому – выпущенный единолично продукт, для разработки которого пришлось с нуля разбираться и с разработкой под IOS, и с разработкой под Android, и со всем, что надо для создания сложного бэкенда, включая продвинутое администрирование Linux.

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

          Может, вы не поняли о чём я написал, может я с Майкрософтом в статье задел вас за «живое» (не переживайте, в одной из следующих статей я наоборот буду его хвалить), а может просто у вас было плохое настроение, и вы искали с кем «пободаться» – в любом случае я не навязываю никому своего мнения, а, как я и написал в начале статьи, цель написанного (конечно, кроме пиара своего продукта:-) ) – сократить количество вопросов относительно моих «неправильных» решений, которые будут описаны в последующих статьях.
          • 0
            Мне кажется, что вы неверно истолковываете нашу дискуссию как переход на личности. Вы излагаете от первого лица определенный опыт и наблюдения, а я с рассказчиком не соглашаюсь. Этот рассказ касается индустрии вцелом, и, с вашего позволения, выводы сделанные рассказчиком мне представляются далекими от действительности.

            Конечно, «сколько людей, столько и мнений». Но в статье приведены и конкретные факты, на которых основываются сделанные выводы. Эти факты подвергаются сомнению и критике, что в свою очередь снижает доверие к сделанным выводам.

            Что же касается Microsoft, Cisco, VMware, да и в общем любого другого вендора, я к ним не питаю особой симпатии. Компании продают инструменты для работы, есть преимущества, есть недостатки, но все они по сути одинаковы. Хотите ругайте, хотите хвалите. Если в конкретных технологических деталях будет ошибка — мы вас поправим.

            Курсы, сертификации, для IT Pro сейчас переживают не лучшие времена. В 80% случаев это курсы уровня 100, то есть для самых начинающих. Если вы полный ноль в этом направлении — будет хорошим стартом. Если нет, вы зря потратите деньги. Сертификации варьируются от элементарных до вырвимозгных. При этом самостоятельная ценность большинства из них сведена к минимуму дампами. Вендоры с этим не хотят бороться, и даже подозреваю почему.

            То, что вы освоили множество сложных и интересных технологий, несомненно делает вам честь. Просто хотелось бы, чтобы вы и рассказывали о том, в чем действительно разбираетесь, в том как сложно или просто начать разработку под IOS, как с нуля грамотно спроектировать бэкэнд и т.д. Об этом интересно почитать.
            • 0
              Технические статьи тоже будут. Полного раскрытия «внутренностей» я не сделаю, т.к. там есть несколько «ноу-хау» которые я не хотел бы выносить в паблик, но все этапы разработки «с нуля», включая выбор инструментария, постараюсь осветить. А вот насколько я в этом разбираюсь и насколько «грамотными» были мои решения – я и сам понятия не имею, т.к. ориентиров не было. Именно поэтому первая статья была именно о том, о чём она была. А вообще, кроме технического, оттенок в большинстве статей всё-таки будет ещё и эмоциональный, как и в этой статье, т.к. не имея опыта в этих технологиях и руководствуясь исключительно здравым смыслом в создании с нуля чего-то совершенно нового я постоянно находился (и нахожусь) в сомнениях относительно принятых как технических, так и стратегических решений. Я не верю, что подобные вопросы беспокоят только меня, поэтому решил не игнорировать эмоциональную часть этого процесса.

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

Самое читаемое Управление