[comp; life] Как узкому специалисту удачно продать себя?

Представьте себе, что вы “узкий” специалист – сильно увлеченный какой-то специфической областью классный программист. Например, вы занимаетесь компиляторами, графическими движками для CAD систем, распределенными БД для исторических данных, lock-free алгоритмами и т.д. И вы хотите удачно продать себя. Т.е. обеспечить себе (очень) хороший заработок и получить возможность дальше заниматься любимым делом. И задаетесь вопросом: “Как это сделать?”

К сожалению, ответа у меня нет. Я не смог найти его лет десять назад для самого себя, хотя и хотелось, чтобы мои наработки в области самописной объектной СУБД не пропали даром. Поэтому ниже следуют рассуждения на тему, в которой я не разбираюсь.

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

Итак, мне кажется, что продать можно либо продукт, либо бренд.

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

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

Но и это еще не все. Нам же интересно некое специфическое направление и нам хочется им заниматься. Так вот, как только мы начнем делать собственный продукт, нам все меньше и меньше придется уделять времени своему любимому увлечению. Поскольку, во-первых, даже в области технической части нужно будет сделать много всего разного (GUI какой-нибудь, вспомогательные инструменты, документацию и примеры). И, во-вторых, все больше и больше времени будут занимать организационные вопросы. Так что, если дело пойдет, то придется переквалифицироваться из технаря во владельца бизнеса. Что несколько расходится с первоначальной постановкой задачи о том, чтобы копаться в своей узкой области за хорошие деньги… Засада.

Теперь поговорим о брендах. Брендом должны стать мы сами. Т.е. мы должны продавать самих себя за счет своей репутации, а наше имя должно быть сильно на слуху (хотя бы в узких кругах). За счет чего это можно сделать? Либо за счет продукта-бомбы, либо за счет публикаций. Продукт-бомба (что-то новое, что меняет отношение людей к чему-то, вроде WinAmp-а или BitTorrent-а) – это очень похоже, на то, что уже обсуждалось выше. Нужна идея. И не просто идея. А супер-пупер идея.

Блин, тут какое-то логическое противоречие. Если у нас есть супер-пупер идея, и есть основанный на ней продукт, то зачем нам превращать свое имя в бренд? Лучше сосредоточиться на развитии продукта. Получается, чтобы наше имя стало брендом, нам нужна супер-пупер идея и продукт, которые принесут нам знаменитость, но не принесут достаточного количества денег. Лично я бы супер-пупер продукту без прибыли предпочел бы безыдейный продукт с прибылью…

Но не все так плохо. Можно получить себе имя на продукте, который формально будет принадлежать не нам. Томпсон не был владельцем Unix-а, Керниган и Ричи не были владельцами C, Страуструп – владельцем C++, Хейлсберг – владельцем Delphi и C#, Гослинг – владельцем Java. Но нужно заметить, что из вышеперечисленных только Хейлсберг был взят на работу как узкий специалист по разработке языков программирования (опять же за счет собственного продукта). Остальные стали “случайными” изобретателями и до создания своих знаменитых детищ, они были узкими специалистами в других областях (если мне не изменяет мой склероз).

Значит, нужно рассматривать вариант с супер-пупер публикациями. Тут дело, вроде бы, выглядит получше. Как кто-то хорошо сказал (кажется это был Стив Эгг) – самые знаменитые программисты знамениты не своим программами, а своими книгами. Вот, например, что написал Андрей Александреску? Книгу “Modern C++ Design” и кучу статей, ну и еще библиотеку Loki для C++ и часть стандартной библиотеки для D 2.0. А что еще? Вот в том-то и дело.

Итак, знаменитые программисты-писатели (или писатели-программисты) не сделали знаменитых программных продуктов. Однако, они сделали не менее сложную штуку: они написали знаменитые книги. Что не менее сложно. Поскольку бумагомарателей во всем мире толпы, и чтобы среди них не потеряться, нужна опять таки хорошая идея. Плюс чуточку везения.

---

Пора подводить итог.

Какое слово я употреблял выше чаще всего? Думаю, что слово “идея”.  Это и есть ключевой момент. Нужно придумать, что будет продаваться. Что-то нужное потребителю. Не наши знания, не наши способности. Поскольку покупатели не знают, что с этим делать. Поэтому следует дать им то, что им знакомо.

Книгу о том, как можно делать что-то более быстро, качественно и дешево, чем раньше.

Консультации, которые позволят решать проблемы клиентов быстрее, качественнее и дешевле, чем раньше.

Программный продукт, который позволяет решать задачи клиентов быстрее, качественнее и дешевле, чем раньше.

Как же все просто на словах. Аж жуть берет.

---

PS. Данная заметка возникла в результате чтения обсуждения вопроса Дмитрия Вьюкова на RSDN: “Есть ли спрос на multithreading/concurrency/synchronization?”
И у меня есть просьба к читателям моего блога. Пожалуйста, уделите этому вопросу несколько минут вашего времени. Может вы нуждаетесь или не нуждаетесь в специалисте по multithreading/concurrency? Может вы сталкивались с проблемами в старых многопоточных программах, которые требовалось быстро найти и устранить, а это не получалось? Может вы пытаетесь использовать какую-то стороннюю библиотеку для многопоточности (Intel TBB, Cilk++ и пр.), но это плохо получается из-за отсутствия специалистов, к которым можно обратиться за помощью? Может вы устали искать какой-то специфический инструмент для задействования мощностей multicore процессоров в ваших задачах? Может вы не встречали толковых книг по современной многопоточности, многоядерности и средствам синхронизации? Может вы хотели бы посетить курсы по этой теме? Скажите Диме об этом.