Tagged: команда

История c ивестициями в Storeenv

Интересная история: How I Got Kicked Out of Y Combinator and Then Raised $1.5m for My Startup

Если кратко то: несколько парней сделали и запустили storenvy.com, что-то про интернет магазины. Одному из авторов, а именно Jon Crawford'у, захотелось все это развивать дальше, для чего он поехал в Y Combinator за инвестициями. Ему согласились их дать. Была лишь небольшая проблема — он, и его партнеры, жили в других штатах, а по условиям Y Combinator'а нужно было преехать в калифорнию. Ну вроде как не особо сложно, особенно в америке, собрал вещи да полетел. Но его партнеры не захотели, они уже запустили что-то про продажу футболок, конечно на базе своего storeenv, т.е. у них и так все хорошо и напрягаться им незачем. Предстояло лететь одному, а нанять людей, когда будут деньги, казалось бы не проблема.

Так вот, тут самое интересное: Y Combinator узнав об этом отказался от инвестиций.

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

Помоему это хороший пример того что важна именно команда, а не идея, и иногда даже не продукт и не автор.

P.S.: автор потом нашел партнеров, уже в калифорнии, потратив полгода, но это уже совсем другая история.

Кого стоит брать в команду

Тут Максим Спиридонов писал о том как выбирать работника-фрилансера, и в начале меня несколько смутил этот пост. Добавлю свои 5 копеек, тем более что там еще и конкурс. Так вот, я, конечно, тоже неоднократно искал людей на free-lance.ru, с ним все понятно. Дело в том что я считал что у Максима, с таким портфелем и историей проектов, есть уже сплоченная команда, сидящие в офисе с красивым видом и т.д. На самом деле я не учел профиль его бизнеса. А это очень влияет на то где, как и кого стоит искать.

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

Так вот когда кого нанимать? Казалось бы второй вариант он универсальней. Но первый как минимум менее рискованный и часто гораздо проще осуществимый.
Continue reading

Вопросы на собеседовании

Всегда не понимал вопросы на собеседовании из серии «а какие методы есть у класса Object?», «в чем отличия left/right outer/inner join'ов». Для чего нужны такие вопросы? Какие выводы можно сделать из ответов? Ну вот ответил кандидат, и что? Он хороший программист? Не ответил — плохой? Я не понимаю какой вывод можно сделать. Наверное спросить можно, но лишь к слову. Но еще интересней вопросы из серии «чему будет равен логарифм по основанию 2 от 10 миллионов». Это вообще к чему???

Я не вижу смысла задавать вопросы, на которые можно получить ответ задав один очевидный запрос в гугле и получит ответ в первых 3-4 ссылках.

Каждую задачу должен решать инструмент приспособленный для нее. В случае с логарифмом это калькулятор (или тотже гугл). А человек лучше приспособлен для креативных задач. И нам не нужно обратного.

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

Имхо это некоторое сочетание из (помимо знания конкретной технологии):

  • абстрактного мышление
  • наличия своего мнения
  • умения продумать на шаг вперед
  • общего кругозора и знакомства со смежными областями
  • увлеченности

Что я забыл? И как все это проще всего выяснить?

Конфликты команды разработчиков

В предыдущей заметке про психологические роли разработчика я сказал что они явно конфликтуют друг с другом, и я утверждал что это конфликт очень важен. Т.е. я вообще сторонник того что конфликт это нормально, он нужен, если его видеть, правильно понимать и направлять на благо компании и его участников. А если нет конфликта, и два человека полностью согласны во всем друг с другом, имеют один взгляд во всем, то зачем нужен второй человек?
Continue reading

Психологические роли разработчика

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

Он выделил 4 роли: Producer — Administrator — Enterpreneur — Integrator — сокращенно PAEI. Адизес описал все в общем случае, мне же это интересно на примере команды разработки ПО. Только я позволю себе перевести названия ролей не дословно.
Continue reading