lalaki

Это вопрос управленческий, в котором и знания/опыт нужны хорошие управленческие.

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

Для более полной теории гуглить 1) «модель Такмана» 2) про различия в способах коммуникации.

1. Инфа: в первую очередь читайте Venture Deals — лучшая книга для предпринимателя по общению с инвесторами. Работает и у нас (с оговоркой на конкретные тонкости реализации, но сами условия и договоренности практически идентично работают)

2. Помощь: могу проконсультировать — конфиденциально, безвозмездно. Работаю старшим аналитиком в инвестфонде (Softline Venture Partners), такие вопросы знаю на практике.

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

Для управленца: 1) ключевые навыки и результаты — кратко, лаконично, не marketing language и перечисление функциональных навыков, а управленческие навыки, качества и результаты простыми человеческими словами; 2) рекомендации — не обязательно начальства, но и бывших «подчиненных», коллег, партнеров

вообще, это хорошая зацепка для дискуссии с человеком, показывающей интеллект/мировоззрение/характер/этику и тп, что важнее текущих навыков.

Первое ощущение — «многа букав», стремление кратко излагать свои тезисы очень важно по нескольким причинам.
Также кажется, что эго выпирает, но и есть возможная незаурядность.

Поэтому в итоге пригласил/позвонил бы, чтобы уже лично понять — есть ли что-то, кроме эго.

Чем выше степень неопределенности в проекте, тем критичнее эффективная коммуникация. Чем дальше от общения лицом к лицу, тем коммуникация хуже по всем параметрам.

Можно поискать сервисы по ключевым словам «saas invoicing» — обычно они вокруг такого функционала и сосредоточены, кроме непосредственно отсылки счетов. Один из лидеров — freshbooks.

Интересные готовые к продаже железки для защищенного хранения данных: samurai24.ru/

На севере (Дмитровская, 5 мин от метро) есть Дизайн-завод «Флакон»

Они создали интересное средоточие дизайнеров, сейчас там же создают стартап-платформу, уже есть коворкинг.

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

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

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

Начинать можно ретроспективно — пытаться понять, почему именно такие результаты уже сделанной работы, выделять, чего Вам не хватает для понимания. Затем отслеживать уже найденные факторы — вручную, можно не на всех задачах.

В начале пути бывает достаточно понять «на пальцах» главные проблемы и начать тут же их исправлять, отслеживая так же «на пальцах».

Минусую очень редко, но как правило за лень — явно недоделанную или неряшливую статью. Не минусую тех, с кем просто не согласен, особенно комментарии — разве что если не согласен в этическом плане.

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

x,y — не свойства самой страницы как элемента данных, а свойства представления конкретной страницы, к тому же, вычисляемые:

в общее представление, условно «ленту страниц», передается порядок следования страниц, а оно по их размерам вычисляет расположение.

поэтому отдельно должно быть изменение размера страницы — в самой странице, отдельно — изменение расположения — в представлении, при этом они должны быть связаны.

Вариантов много, простейший и универсальный для MVC: «1) изменить данные; 2) обновить представление»: вызывается сначала изменение размера страницы, затем — перерисовка представления, каждый делает свое.

Можно покопать аналогичные элементы интерфейса в разных языках и библиотеках — посмотреть, как там, т.к. задача типовая.

Если хочешь получить в первую очередь квалификацию, пляши от предметов.
Советую освоить всю математику и программирование по программе и учебникам ВМК МГУ за 1-2 курсы. Самое важное — матан, линал и программистские дисциплины. Дальше — разве что дифуры (не помню, на 2-м или на 3-м курсе они).

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

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

Дальше можно забить на математику, если особого интереса нет, изучать чисто промышленное программирование. На ВМК с этим плохо, лучше всего ИМХО уже на вузы не полагаться, но сам решишь.

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

Scrum — это здравый смысл + базовые навыки командного менеджмента в применении к разработке ПО (как правило).

Здравый смысл приходит в основном с опытом, а для овладения командным менеджментом — коммуникации, управление задачами, коллективом — читайте базовые книги по менеджменту и психологии управления.

Чисто на механическом знании Scrum-ритуалов не выедете, на каком бы системном уровне их не освоили — все время будет что-то не так.

Что посоветую:

Джон Адаир — «Как управлять людьми и самим собой». Очень практичная книга, вплоть до наличия упражнений — нужно не лениться и упражнения выполнять.

Ицхак Адизес — «Идеальный руководитель», «Управляя изменениями». Изложена его методология — must read для любого участника команды.

Михаил Литвак — «Командовать или подчиняться». Прикладная психология — аналогично must read.

+ полезны книги по другим, более нагруженным методологиям — например, «RUP — это легко» — помогают понять, как вообще крутятся шестеренки при разработке ПО и почему и когда хорош Scrum. И какие-либо азы по построению бизнес-процессов — тоже помогают понять, как много общего у разработки ПО с другими отраслями.

если делаете на каком-либо фреймворке, например, Symfony, или хотя бы используете ORM типа Doctrine, решение очевидно: сначала используете дефолтные механизмы ORM — они дадут тривиальное решение, т.е. скорее всего, вариант 1. А оптимизацией занимаетесь по мере необходимости, глядя в профайлер

советую рассмотреть третий вариант:

выбирать не full stack-фреймворк, а решения конкретных типовых задач: они не диктуют, как делать проект, но позволяют не наступать на типовые грабли, уже отполированные лбами тысяч разработчиков.

Например, ORM — одна из областей, в которых велосипеды наименее оправданы: выбирайте из готовых (советую Doctrine) — она и без фреймворка работает.

И так по списку можно попробовать определить и закрыть максимум типовых потребностей, например,
unit-тестирование — PHPUnit, SimpeTest, Lime,
почта — Zend mailer, Swift,
UI: server-side MVC — один набор вариантов, используете SOFEA — гораздо проще с сервером (нет требований), сложнее с клиентом — советую изучить список в sixrevisions.com/javascript/promising_javascript_frameworks/,
и т.п.

В результате получите хотя бы варианты standalone-решений, и даже готовые фреймворки/CMS сможете оценивать на совместимость с этими вариантами.

Роман Прохоров, руководитель SEO в wikimart.ru
— в свое время под личную ответственность его приглашал работать. Честный, адекватный, компетентный, неравнодушный.