IDDQD - Команда молодости нашей, команда, без которой мне не жить.
Warning: под катом и в комментариях - спойлеры.
читать дальше
Есть такая поговорка: "Тяжела и неказиста жизнь простого программиста", в которой, в общем то, есть определённая доля истины - чаще всего разработка софта (и, наверное, железа) не блещет увлекательностью и драматизмом. Кодишь от забора и до обеда, тестируешь, попутно решая те или иные возникающие проблемы. Но... Как убедительно показали создатели сериала Halt and catch fire - даже в этом скучном процессе может найтись место драме. И в каждом эпизоде они это доказывают. Итак...
Эпизод первый. В нём рассказывается о проблемах законодательства в области патентования и защиты авторских прав в США, и о том, как порой бывает сложно сделать что-то новое (но совместимое с другими продуктами на рынке), не попав при этом на скамью подсудимых по делу о нарушении этих самых авторских прав. Нам рассказали и об обратной разработке - основном инструменте получения спецификаций и выяснения деталей устройства того, что производить не желает публиковать, и о юридических последствиях такого рода деятельности. В реальности в такие игры играть довольно опасно, ибо грозит серьёзными репутационными и финансовыми потерями для компании. Но иногда другого выхода попросту не бывает.
Эпизод второй. Основных темы две - "белая комната" и коммерческая дискредитация. "Белая комната" - это единственный способ легализовать результаты обратной разработки. Суть процесса сводится к тому, что один человек реверсит, а другой, находящийся в "белой комнате" пишет код (или создаёт железо) с нуля по спецификациям, полученным от первого. Специальный посредник (адвокат) передаёт спецификации от первого второму и следит за их юридической чистотой. Таким образом потом можно доказать, что компания, ведущая такого рода разработку, не нарушила ни чьих авторских прав. Ну и FUD - грубый способ нечестной конкуренции, когда одна компания (или компании) выдавливают другую с рынка путём дискредитации её продукции, подкупа или запугивания клиентов, демпинга. В серии процесс показан слишком быстро но, таки да. Так оно происходит - заказные статьи в прессе, обзвон клиентуры, обваливание цен, фейковые судебные иски, и прочее, прочее, прочее. Хороший пример того, что чёрный пиар далеко не всегда идёт на пользу дела. Особенно, если в бизнесе немалую роль играет репутация компании.
Третий эпизод. Посвящен проблемам поиска финансирования для стартапов. Несмотря на то, что Cardiff Electric - старая компания, во второй серии она была поставлена в положения, когда вынуждена начинать бизнес с нуля. И тут было показано три основных способа поиска финансирования - венчурные фонды, знакомые толстосумы и собственные ресурсы. В итоге выбран был третий, ибо первые два не понравились либо Босворту, либо Джо. В первом случае проблема заключалась в необходимости внешнего управления и аудита, что, де-факто, передавало компанию в собственность венчурного фонда. Это было не в интересах Босворта и Кардифа. Во втором случае (с толстосумом) проблема была в том, что Джо терять контроль над тем, каким именно будет конечный результат деятельности (ибо, кто платит - тот и музыку заказывает), плюс ко всему Лулу потребовала слишком большой процент с продаж. В итоге - да, решено было обойтись собственными средствами.
Эпизод четвёртый. Страшный сон разработчика (или админа) - он что-то безвозвратно удалил (исходники, бэкапы, бухгалтерскую БД, боевой веб-сервер и т. д. и т. п.). Такое случалось с каждым, и будет ещё случаться. Ибо это можно только пережить, чтобы понять. Даже поговорка такая есть: "Админы делятся на два типа: тех, кто еще не делает бэкапы, и тех, кто уже делает бэкапы." Поговорка, написанная кровью, потом и слезами покрасневших от бессонных ночей глаз. И таки да, большинство известных мне программистов нажимают Ctrl-S не реже одного раза в пять секунд. Выработанный с годами рефлекс.
Эпизод пятый. Тема менеджмента. Кто бы что там не говорил, а программирование - процесс в большой степени творческий, и требующий соответствующей атмосферы и условий. Именно поэтому Кэм оборудовала себе берлогу - это помогало ей работать. Именно поэтому жесткая регламентация процесса, навязываемая менеджментом, нередко этот самый процесс убивает. В серии было показано типичное противостояние менеджмента и разработчиков. Хороший менеджер должен понимать, что разработчик не может всё время педалить код, что от него нельзя требовать жесткой отчётности и соблюдения всех формальностей и регламентов. Что девять беременных никогда не родят ребёнка за месяц, как бы они не старались. И самое лучшее в такой ситуации - требовать в первую очередь соблюдения сроков и качества, а не формальностей. Если менеджер этого всего не понимает - его лучше заменить более адекватным. Что и произошло.
Эпизод шестой. Last minute changes. Хорошо известный факт заключается в том, что только доведя разработку почти до финала, ты начинаешь понимать, с чего же именно стоило начинать и как делать. И в этот момент наступает нестерпимый зуд всё переписать. Ты бежишь к начальству, размахиваешь руками, брызжешь слюной строя воздушные замки и обозначая супероптимистичные сроки переработки. Хороший начальник всё это выслушает, посмотрит на календарь, скажет, что до релиза - два месяца, а еще ничего не тестировалось и отправит исправлять баги. И это в большинстве случаев - единственно правильный вариант, ибо иначе возникает ступор перфекциониста, когда работа бесконечно улучшается, а релиза всё нет и нет, сроки - профачены, клиенты растеряны и ушли к другим поставщикам. Всегда существует момент, когда надо остановиться и удовлетвориться тем результатом, а который уже есть. Бывают исключения, когда возникшая идея - это серьёзное ноу-хау, которое взорвёт рынок. Но риски более позднего старта продаж всегда должны быть адекватно оценены, и, в случае негативной оценки, переработки отодвинуты.
Эпизод седьмой. Извечный конфликт формы и содержания. Широко известный факт заключается в том, что если попросить программиста создать пользовательский интерфейс - скорее всего, этим интерфейсом сможет пользоваться только сам программист. А если то, что создаётся, рассчитывается на массового потребителя (будь то сайт, или программа, или девайс какой-нибудь), то это "что-то" должно выглядеть так, чтобы потребитель это купил. Нанимаются мега-дизайнеры, специалисты по юзабилити, изучается user expirience..., делаются макеты, прогоняются на фокус-группе, согласовываются с заказчиком (если такой имеется). А потом на всё это смотрит разработчик/схемотехник и чешет репу в размышлении - а как же он всё это реализовывать будет? Но, он же "эксперт" и легко может нарисовать семь красных линий, три из которых - прозрачные, четыре - нарисованы зелёным цветом, ну и далее по тексту. По этому берёт в руки дизайн-макет, наливает чашку кофе и начинает реализовывать все эти гениальные задумки. А потом прибегает взмыленный ПМ или дизайнер, и радостно сообщает, что концепция поменялась, и теперь всё совсем-совсем по-другому, и что клиенту просто необходима вот такая вот свисто-перделка серобурмалинового цвета, которая будет ещё и кофе заваривать...
Эпизод восьмой. Хакерство и компьютерные преступления. Как это ни странно, но информационные системы уязвимы. Они содержат ошибки, "дырки", чёрные ходы. Зачастую разработчики даже не предполагают, что от каких-то вещей надо бы защищаться. В итоге - находятся люди, которые этим пользуются в своих корыстных и не очень целях. Какое-то время их называли хакерами. Сейчас чаще используется термин "кибер-преступник". Или "кибер-воин", потому как этими же средствами можно наносить весьма ощутимый (и, зачастую, реальный) урон противнику. Иногда кого-то ловят и сажают, но такое, увы, происходит далеко не всегда. Распространяться дальше на эту тему мог бы ещё долго, но не буду. Кому интересна текущая ситуация - об этом хорошо и подробно пишут, например, на SecureList люди, которые
профессионально занимаются этими вопросами.
Эпизод девятый. О да, побеждает не тот, кто лучше, а тот, кто первый. Да, кто первый встал - того и тапки. Таковы законы конкуренции в том числе и в сфере ИТ. В ход идут любые средства. И промышленный шпионаж, и блеф, и заманухи, и многое-многое другое. Обычная дилемма проджект-менеджера (или менеджера проекта) - выпустить сырой продукт на рынок, или подождать ещё, допилить, но позволить первым выпустится конкурентам? Ставки в этом вопросе тем более растут, что победитель зачастую получает всё. Особенно, если продукт (пусть и сырой) действительно выстрелил. В сфере B2B вообще может доходить до абсурда (правда, довольно таки типичного) - продаётся то, что ещё даже не написано...
А вот именно IT-тему десятого эпизода уловить не могу. Тут тематика носит общефилософский характер.
UPD: Добавлено описание эпизодов с 7-го по 10-ый.
читать дальше
Есть такая поговорка: "Тяжела и неказиста жизнь простого программиста", в которой, в общем то, есть определённая доля истины - чаще всего разработка софта (и, наверное, железа) не блещет увлекательностью и драматизмом. Кодишь от забора и до обеда, тестируешь, попутно решая те или иные возникающие проблемы. Но... Как убедительно показали создатели сериала Halt and catch fire - даже в этом скучном процессе может найтись место драме. И в каждом эпизоде они это доказывают. Итак...
Эпизод первый. В нём рассказывается о проблемах законодательства в области патентования и защиты авторских прав в США, и о том, как порой бывает сложно сделать что-то новое (но совместимое с другими продуктами на рынке), не попав при этом на скамью подсудимых по делу о нарушении этих самых авторских прав. Нам рассказали и об обратной разработке - основном инструменте получения спецификаций и выяснения деталей устройства того, что производить не желает публиковать, и о юридических последствиях такого рода деятельности. В реальности в такие игры играть довольно опасно, ибо грозит серьёзными репутационными и финансовыми потерями для компании. Но иногда другого выхода попросту не бывает.
Эпизод второй. Основных темы две - "белая комната" и коммерческая дискредитация. "Белая комната" - это единственный способ легализовать результаты обратной разработки. Суть процесса сводится к тому, что один человек реверсит, а другой, находящийся в "белой комнате" пишет код (или создаёт железо) с нуля по спецификациям, полученным от первого. Специальный посредник (адвокат) передаёт спецификации от первого второму и следит за их юридической чистотой. Таким образом потом можно доказать, что компания, ведущая такого рода разработку, не нарушила ни чьих авторских прав. Ну и FUD - грубый способ нечестной конкуренции, когда одна компания (или компании) выдавливают другую с рынка путём дискредитации её продукции, подкупа или запугивания клиентов, демпинга. В серии процесс показан слишком быстро но, таки да. Так оно происходит - заказные статьи в прессе, обзвон клиентуры, обваливание цен, фейковые судебные иски, и прочее, прочее, прочее. Хороший пример того, что чёрный пиар далеко не всегда идёт на пользу дела. Особенно, если в бизнесе немалую роль играет репутация компании.
Третий эпизод. Посвящен проблемам поиска финансирования для стартапов. Несмотря на то, что Cardiff Electric - старая компания, во второй серии она была поставлена в положения, когда вынуждена начинать бизнес с нуля. И тут было показано три основных способа поиска финансирования - венчурные фонды, знакомые толстосумы и собственные ресурсы. В итоге выбран был третий, ибо первые два не понравились либо Босворту, либо Джо. В первом случае проблема заключалась в необходимости внешнего управления и аудита, что, де-факто, передавало компанию в собственность венчурного фонда. Это было не в интересах Босворта и Кардифа. Во втором случае (с толстосумом) проблема была в том, что Джо терять контроль над тем, каким именно будет конечный результат деятельности (ибо, кто платит - тот и музыку заказывает), плюс ко всему Лулу потребовала слишком большой процент с продаж. В итоге - да, решено было обойтись собственными средствами.
Эпизод четвёртый. Страшный сон разработчика (или админа) - он что-то безвозвратно удалил (исходники, бэкапы, бухгалтерскую БД, боевой веб-сервер и т. д. и т. п.). Такое случалось с каждым, и будет ещё случаться. Ибо это можно только пережить, чтобы понять. Даже поговорка такая есть: "Админы делятся на два типа: тех, кто еще не делает бэкапы, и тех, кто уже делает бэкапы." Поговорка, написанная кровью, потом и слезами покрасневших от бессонных ночей глаз. И таки да, большинство известных мне программистов нажимают Ctrl-S не реже одного раза в пять секунд. Выработанный с годами рефлекс.
Эпизод пятый. Тема менеджмента. Кто бы что там не говорил, а программирование - процесс в большой степени творческий, и требующий соответствующей атмосферы и условий. Именно поэтому Кэм оборудовала себе берлогу - это помогало ей работать. Именно поэтому жесткая регламентация процесса, навязываемая менеджментом, нередко этот самый процесс убивает. В серии было показано типичное противостояние менеджмента и разработчиков. Хороший менеджер должен понимать, что разработчик не может всё время педалить код, что от него нельзя требовать жесткой отчётности и соблюдения всех формальностей и регламентов. Что девять беременных никогда не родят ребёнка за месяц, как бы они не старались. И самое лучшее в такой ситуации - требовать в первую очередь соблюдения сроков и качества, а не формальностей. Если менеджер этого всего не понимает - его лучше заменить более адекватным. Что и произошло.
Эпизод шестой. Last minute changes. Хорошо известный факт заключается в том, что только доведя разработку почти до финала, ты начинаешь понимать, с чего же именно стоило начинать и как делать. И в этот момент наступает нестерпимый зуд всё переписать. Ты бежишь к начальству, размахиваешь руками, брызжешь слюной строя воздушные замки и обозначая супероптимистичные сроки переработки. Хороший начальник всё это выслушает, посмотрит на календарь, скажет, что до релиза - два месяца, а еще ничего не тестировалось и отправит исправлять баги. И это в большинстве случаев - единственно правильный вариант, ибо иначе возникает ступор перфекциониста, когда работа бесконечно улучшается, а релиза всё нет и нет, сроки - профачены, клиенты растеряны и ушли к другим поставщикам. Всегда существует момент, когда надо остановиться и удовлетвориться тем результатом, а который уже есть. Бывают исключения, когда возникшая идея - это серьёзное ноу-хау, которое взорвёт рынок. Но риски более позднего старта продаж всегда должны быть адекватно оценены, и, в случае негативной оценки, переработки отодвинуты.
Эпизод седьмой. Извечный конфликт формы и содержания. Широко известный факт заключается в том, что если попросить программиста создать пользовательский интерфейс - скорее всего, этим интерфейсом сможет пользоваться только сам программист. А если то, что создаётся, рассчитывается на массового потребителя (будь то сайт, или программа, или девайс какой-нибудь), то это "что-то" должно выглядеть так, чтобы потребитель это купил. Нанимаются мега-дизайнеры, специалисты по юзабилити, изучается user expirience..., делаются макеты, прогоняются на фокус-группе, согласовываются с заказчиком (если такой имеется). А потом на всё это смотрит разработчик/схемотехник и чешет репу в размышлении - а как же он всё это реализовывать будет? Но, он же "эксперт" и легко может нарисовать семь красных линий, три из которых - прозрачные, четыре - нарисованы зелёным цветом, ну и далее по тексту. По этому берёт в руки дизайн-макет, наливает чашку кофе и начинает реализовывать все эти гениальные задумки. А потом прибегает взмыленный ПМ или дизайнер, и радостно сообщает, что концепция поменялась, и теперь всё совсем-совсем по-другому, и что клиенту просто необходима вот такая вот свисто-перделка серобурмалинового цвета, которая будет ещё и кофе заваривать...
Эпизод восьмой. Хакерство и компьютерные преступления. Как это ни странно, но информационные системы уязвимы. Они содержат ошибки, "дырки", чёрные ходы. Зачастую разработчики даже не предполагают, что от каких-то вещей надо бы защищаться. В итоге - находятся люди, которые этим пользуются в своих корыстных и не очень целях. Какое-то время их называли хакерами. Сейчас чаще используется термин "кибер-преступник". Или "кибер-воин", потому как этими же средствами можно наносить весьма ощутимый (и, зачастую, реальный) урон противнику. Иногда кого-то ловят и сажают, но такое, увы, происходит далеко не всегда. Распространяться дальше на эту тему мог бы ещё долго, но не буду. Кому интересна текущая ситуация - об этом хорошо и подробно пишут, например, на SecureList люди, которые
профессионально занимаются этими вопросами.
Эпизод девятый. О да, побеждает не тот, кто лучше, а тот, кто первый. Да, кто первый встал - того и тапки. Таковы законы конкуренции в том числе и в сфере ИТ. В ход идут любые средства. И промышленный шпионаж, и блеф, и заманухи, и многое-многое другое. Обычная дилемма проджект-менеджера (или менеджера проекта) - выпустить сырой продукт на рынок, или подождать ещё, допилить, но позволить первым выпустится конкурентам? Ставки в этом вопросе тем более растут, что победитель зачастую получает всё. Особенно, если продукт (пусть и сырой) действительно выстрелил. В сфере B2B вообще может доходить до абсурда (правда, довольно таки типичного) - продаётся то, что ещё даже не написано...
А вот именно IT-тему десятого эпизода уловить не могу. Тут тематика носит общефилософский характер.
UPD: Добавлено описание эпизодов с 7-го по 10-ый.
@темы: Интересности, Смотрим
Ну, во-первых, речь идёт в принципе о способности ставить точку. Т. е. понимать, когда нужно релизится. И о ступоре перфекциониста (которым, как выяснилось, страдает Джо).
Во-вторых, о том, что в команде должен быть человек, который формирует вижн и создаёт драйв. Он может особо ничего не делать, но вдохновлять других на подвиги. Это очень важно.
В-третьих, речь о том, что мечты об идеале далеко не всегда совпадают с реальностью. Именно по этому Джо фрустрирует всю серию. Ведь "Гигант" - это не то, о чём он мечтал.
интересно было читать разбор
Беда борьбы мечты с реальностью. Реальность, обычно, побеждает. У Джо тупо не хватило терпения/желания/нервов продолжать, кажется.
Возможно. Но больше похоже на то, что у него конфликт в голове - конфликт идеального и реального.
Тоже есть такое. Но он создал хороший продукт, появились деньги и возможность хоть чего с ним делать, какие угодно навороты впихивать в эту коробочку. Доводить до своего идеала.
Собственно, так строится все что мы видим.
Не совсем. Если у тебя куча-куча-куча-денег - ты можешь делать продукт с какими угодно наворотами, и бесконечно его допиливать и вылизывать, доводя до состояния собственного идеала. В реальности (знакомой мне) есть ограниченные бюджеты, сроки, конкуренты, и проч. порч. проч., что мешает получить этот самый идеал. Вот, как выяснилось, Джо именно к этому и не готов.
Когда есть возможность делается - долго доводимая до идеала - "мечта".
"Мечта", обычно, дорогая по стоимости, на малый сегмент рынка.
Это, как мы называем, имеджевый продукт.
Компьютерный рынок я не изучала специально, но практически у всех производителей есть линейка премиум класса, типа феррари у асусов.
Любой продукт на кого-то доложен быть ориентирован, лично для себя это: за свои деньги, своим паяльником, на своей кухне.
Относительно HACF, Джо слишком профи чтоб такой херней страдать.
У него там попоболь именно от того что он узрел что кто-то уже начал воплощать его мечту, пока они ходили кругами и впихивали невпихуемое.
Есть, есть, страдают.
Джо слишком профи чтоб такой херней страдать.
Тем не менее, именно ею он и страдает. И об этом вся последняя серия. И несмотря на то, что в середине сериала он говорит Кэм такую зажигательную речь про захват рынка, и всё такое, на самом деле "ещё одну бежевую коробку с MS-DOS" он выпускать не хотел.
А да, знакомо
Знаю пару онлайн игрушек которые лет 7 уже как были обещаны
на самом деле "ещё одну бежевую коробку с MS-DOS" он выпускать не хотел.
У него ситуация шаткая, как-то все рассыпаться начало в 8-й серии. Был выбор......точнее не было выбора - только, выпускать что-то продаваемое и садиться в кресло Босворта задавив Кардиффа перспективами прибыли. Как он и сделал.
И он это сделал.
Хотя, то что ПК в самый нужный момент дал сбой это фейл и им еще очччень повезло что так все обернулось.
Я уже говорила, не понимаю почему он все бросил. Перспективы были очень хорошие: прибыль пошла, вполне можно было какой-то процент выделить и заниматься "мечтой".
Мне кажется что это просто нормальный стиль поведения для Джо. Очень по детски психануть получив на ДР самолетик вместо вертолетика.