19 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-what-to-do-in-a-sales-meeting.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: What to do in a sales meeting?
3 | category: Business
4 | ---
5 |
6 | 1. **Shut up and let the client talk**. Your goal is to make him tell you as much about himself, his organization and his problems. Which means you need to...
7 | 1. **Ask questions**. Lead the client gently toward a conversation about how your services can provide benefit
8 | 1. **Pay attention and take notes**. Show investment in the conversation and the client's time. Also, you never know what you might forget!
9 | 1. **Follow up immediately after the meeting**. As soon as possible, get an email out thanking the client for her/his time, recapping what was covered, and laying out next steps for both parties. This demonstrates a lot of value to prospective clients.
10 |
--------------------------------------------------------------------------------
/_includes/favicons.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-projects-pipelines.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Pipelines for Projects
3 | category: DevOps
4 | ---
5 |
6 | [Pipelines](https://github.com/Wiredcraft/pipelines) is used to automate operations at Wiredcraft.
7 |
8 | The automation bits being numerours, we split them per project, allowing to keep the various tasks grouped together. It also allows more granular access to what and who could trigger pipelines.
9 |
10 | ## Project's pipelines
11 |
12 | We use Pipelines to automate the creation of pipelines!
13 |
14 | On the Pipelines main admin:
15 |
16 | - Click on "Create new Pipelines instance"
17 | - Fill the domain name in the prompt
18 | - Fill the admin / pass in the prompt
19 | - Press run and wait for completion
20 |
21 | Your new Pipelines instance is available at the new domain https://domain
22 |
23 | Debugging
24 | ---------
25 |
26 | Refer to the ops team.
27 | Work in progress.
28 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-a-few-traditions.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: A few traditions
3 | category: Company
4 | ---
5 |
6 | - **If something breaks, it's the latest hire's fault**. We like to jokingly blame our latest recruit for things that are obviously not their fault.
7 | - **We have a monthly team building**. The whole team usually takes a Friday afternoon to go enjoy an activity (e.g. karting, bowling, archery) and then have dinner together. We also have larger dinners for special occasions (e.g. Christmas, Chinese New Year).
8 | - **We have a weekly team lunch on Friday**, sometimes with a presentation from one of the team members (although [this is still being discussed right now](https://github.com/Wiredcraft/wiredcraft.github.io/issues/2244#issuecomment-187641759)).
9 | - **We have a company off-site at least once a year**. In previous years, we've sent the team to Moganshan, Berlin and Prague. This is usually a time to work on side projects, relax and get closer.
10 |
--------------------------------------------------------------------------------
/assets/favicons/safari-pinned-tab.svg:
--------------------------------------------------------------------------------
1 |
2 |
4 |
19 |
--------------------------------------------------------------------------------
/_sass/custom/_main.scss:
--------------------------------------------------------------------------------
1 | .page-front {
2 | #hero {
3 | background: $light;
4 | }
5 | }
6 |
7 | #content {
8 | .breadcrumb {
9 | @include font-size($smaller);
10 | line-height: 160%;
11 | }
12 | .navigation {
13 | background: $light;
14 | border-radius: $radius;
15 | box-sizing: border-box;
16 | float: left;
17 | @include font-size($smaller);
18 | line-height: 160%;
19 | padding: 1.5*$space/2;
20 | padding-bottom: $space - $space/4;
21 | width: 25%;
22 | a.active {
23 | color: inherit;
24 | }
25 | ul {
26 | list-style: none;
27 | margin: 0;
28 | padding: 0;
29 | li li {
30 | margin-left: 1.5*$space/2;
31 | }
32 | }
33 | }
34 | .body {
35 | box-sizing: border-box;
36 | float: right;
37 | padding-left: 2*$space;
38 | width: 75%;
39 | }
40 | }
41 |
42 | .icon {
43 | display: inline-block;
44 | height: $space;
45 | width: $space;
46 | }
47 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-branding-style.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Branding
3 | category: Company
4 | ---
5 |
6 | ## Visual identity
7 |
8 | We're maintaining our visual identity on figma: https://www.figma.com/file/SAuHOy5r7vsd4IFg6jcFcjRp/Wiredcraft-logo
9 |
10 | - **Typography**:
11 | - [Galano Grotesque](https://www.myfonts.com/fonts/rene-bieder/galano-grotesque/) Bold for the wordmark.
12 | - [Montserrat](https://fonts.google.com/specimen/Montserrat) Extra-Bold for headlines.
13 | - [Nunito Sans](https://fonts.google.com/specimen/Nunito+Sans) Light for content.
14 | - **Colors**:
15 | - Black: #000000
16 | - Red: #EF233C
17 |
18 | ## Email signature
19 |
20 | > Ronan Berder
21 | > –––
22 | > CEO & Founder
23 | > Wiredcraft - Engineering innovation
24 | > Mobile: (+86) 138 8888 8888
25 | > [Wiredcraft.com](https://wiredcraft.com/) / [Twitter](https://twitter.com/wiredcraft) / [Facebook](https://www.facebook.com/teamwiredcraft/) / [LinkedIn](https://www.linkedin.com/company/wiredcraft/)
26 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-growth-performances-and-raises.md:
--------------------------------------------------------------------------------
1 | ---
2 | sticky: true
3 | title: Growth, Performances & Raises
4 | category: Employees
5 | ---
6 |
7 | We mostly do things to track performance and growth;
8 |
9 | - **1-on-1** happen monthly. They're a simple face-to-face discussions between each team member and their manager. This is not only an opportunity for employees to get feedback on their performance and progress, but also sharing ideas on what the company and manager could improve on.
10 | - **Performance reviews** happen every 6 months. They focus on the work performance of employees and directly impact raises, bonuses & promotions. It usually cover the following;
11 | - **Past performance**; we go over the previous 6 months, review the work that has been done and the achievements that came out of it.
12 | - **Employee feedback**; we gather feedback directly from the individual and try to identify issues or support he may be lacking.
13 |
14 | We constantly adjust the organization and colleagues responsibilities based on the 1-1, but we only consider raises or promotions at the performance review every 6 months.
15 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-overtime.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Overtime work & Holidays
3 | category: Employees
4 | ---
5 |
6 | ## Overtime
7 |
8 | We don't like overtime. But we sometimes have to push through a delivery, or accomodate a particular schedule.
9 |
10 | **What counts as overtime work?**
11 | Overtime work is any work related to projects, tasks or events which are outside of regular working hours.
12 |
13 | **How will overtime work be compensated?** Overtime work **can be added up to 5 days per contract period**. If the sum of overtime work exceeds this limitation, it will be compensated with payment according to the laws of the particular location the team member is working at.
14 |
15 | ## Carry over of holidays to the new contract period
16 |
17 | Team members are allowed to **carry over up to 2 holiday days** from the old contract period to the new one. These 2 days need to be taken within the first 3 months of the new contract period. If the team member misses this limitation, holiday days will expire.
18 |
19 | Note that this includes free time which has been earned due the attendence of conferences or meetups Wiredcraft organised.
20 |
--------------------------------------------------------------------------------
/_sass/partials/_notification.scss:
--------------------------------------------------------------------------------
1 | @if index($partials, notification) {
2 | .notification {
3 | border-radius: $radius;
4 | color: #FFF;
5 | display: block;
6 | @include font-size($smaller);
7 | margin-bottom: $space;
8 | padding: $space/4 $space/2;
9 | &.error {
10 | background: lighten($red, 45%);
11 | color: $red;
12 | }
13 | &.success {
14 | background: lighten($blue, 50%);
15 | color: $blue;
16 | }
17 | &.warning {
18 | background: lighten($orange, 38%);
19 | color: $orange;
20 | }
21 | > *:last-child {
22 | margin-bottom: 0;
23 | }
24 | a {
25 | color: inherit;
26 | text-decoration: underline;
27 | &:active,
28 | &:hover {
29 | text-decoration: none;
30 | }
31 | }
32 | .close {
33 | background: transparent;
34 | border: 0;
35 | color: inherit;
36 | float: right;
37 | opacity: 0.5;
38 | padding: 0;
39 | text-decoration: none;
40 | transition-property: opacity;
41 | transition-duration: $ease;
42 | &:hover {
43 | opacity: 1;
44 | }
45 | }
46 | }
47 | }
48 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-how-to-write-content.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: How to write content?
3 | category: Marketing
4 | ---
5 |
6 | Writing content can be hard to get right, but it must for a company to market successfully. Whether it's a blog, social media, newsletter, press pitch, or whatever, it's all content and it needs to be written carefully and masterfully.
7 |
8 | - **Make it useful and/or interesting:** If someone's taking the time out of their lives to read something, it should be exciting or instructive. They want to learn or be entertained, so write to one of both of these objectives.
9 | - **Keep it short, to the point:** Attention spans only get shorter (thanks, Internet) and people want gratification fairly quickly, so spit it out and publish it already.
10 | - **Triple-check all of it:** Mistakes can ruin a message like nothing else, be it grammar, spelling, poor formatting, or a broken link. Check everything three times. Better yet, get a second and third opinion before posting.
11 | - **And show some personality:** Encyclopedias aren't especially fun to read and neither is any content without voice. People write, not machines, so the content should feel like that when it's read.
12 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-contractual-jargon.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Contractual jargon
3 | category: Business
4 | ---
5 |
6 | A contractual lexicon.
7 |
8 | ## Contractual documents
9 |
10 | The contract flow can be seen as such:
11 |
12 | 
13 |
14 | * **NDA (Non-Disclosure Agreement)**
15 | Before signing a contract, a NDA (Non-Disclosure-Agreement) is needed in most cases in order to save both sides interests.
16 |
17 | * **MSA (Master Service Agreement)**
18 | Defines how the two companies will do business together.
19 |
20 | * **SOW (Statement of Work)**
21 | Describes the work to be performed for the client. Note that the MSA defines the “how” and the SOW defines the “what” of the work.
22 |
23 | * **CO (Change Order)**
24 | Change Orders document any changes in scope, budget, timeline, assumptions or any other deviation from the current SOW.
25 |
26 | * **PR/PO (Purchase Request/Purchase Order)**
27 | Usually for bigger companies - in this case in most cases no MSA or SOW needed
28 |
29 | You can read more [here](https://techproductmanagement.com/what-every-product-manager-ought-to-know-about-contract-negotiation/).
30 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-respond-to-emergency.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Respond to emergency
3 | category: Projects
4 | weigh: -6
5 | ---
6 |
7 | It is important to respond to emergencies instead of reacting to them. To ensure continuous learning it is important to reflect on the causes of the emergency. Methods to do so are numerous, we usually prefer conducting a 5 Whys.
8 |
9 | Using iteratively the question "Why?" is used to determine the root cause of a defect or problem. Each answer forms the basis of the next questions. For example:
10 |
11 | 1. *Why did the login failed?*
12 | Because the database was not available.
13 |
14 | 2. *Why did the database was not available?*
15 | Because there was too many requests to the database.
16 |
17 | 3. *Why did the database could not handle the requests loads?*
18 | Because it was not test loaded.
19 |
20 | 4. *Why wasn't it load tested?*
21 | Because it was not part of the tests plan.
22 |
23 | 5. *Why wasn't it part of the tests plan?*
24 | Because it was not an acceptance criteria for the user story.
25 |
26 | For more details on this, we strongly recommend you have a look at [The 5 Whys Process We Use to Understand the Root of Any Problem](https://open.buffer.com/5-whys-process/)
27 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-dealing-with-projects.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Dealing with projects
3 | category: Projects
4 | ---
5 |
6 | To ensure the success of projects we follow 4 core concepts:
7 |
8 | 1. **Transparency**: the clients and team members all have access to the [same information](https://github.com/Wiredcraft/playbook/wiki/Working-with-your-colleagues) and the same communication channels (*e.g.* Github, Slack, Hackpad).
9 | 2. **Traceability**: all actions are clearly outlined and tracked online most likely [Github](https://wiredcraft.com/blog/github-for-everything/) (*e.g.* meeting next steps, migrating emails discussions to issues, actionable discussions from Slack).
10 | 2. **Accountability**: team members and clients are accountable for their respective actionables.
11 | 4. **Rational, not emotional**: make decisions based on the realities of the situation, not on reaction to emotions ([learn to respond, not react](https://zenhabits.net/respond/)).
12 |
13 | **Leading by example** and **enforcing** these concepts is paramount for the project manager and benefits the team members at large.
14 |
15 | A few other concepts to keep in mind:
16 |
17 | * Always under promise and over deliver
18 | * Prototype fast
19 | * Deliver in small incremental batches
20 |
--------------------------------------------------------------------------------
/_sass/utils/_responsive.scss:
--------------------------------------------------------------------------------
1 | @mixin breakpoint($class) {
2 | @if $class == mobile {
3 | @media (max-width: map-get($breakpoints, tablet)) { @content; }
4 | }
5 |
6 | @else if $class == tablet {
7 | @media (min-width: (map-get($breakpoints, tablet) + 1)) { @content; }
8 | }
9 |
10 | @else if $class == only_tablet {
11 | @media (min-width: (map-get($breakpoints, tablet) + 1)) and (max-width: map-get($breakpoints, desktop)) { @content; }
12 | }
13 |
14 | @else if $class == up_to_desktop {
15 | @media (max-width: map-get($breakpoints, desktop)) { @content; }
16 | }
17 |
18 | @else if $class == desktop {
19 | @media (min-width: (map-get($breakpoints, desktop) + 1)) { @content; }
20 | }
21 |
22 | @else if $class == only_desktop {
23 | @media (min-width: (map-get($breakpoints, desktop) + 1)) and (max-width: map-get($breakpoints, highres)) { @content; }
24 | }
25 |
26 | @else if $class == up_to_highres {
27 | @media (max-width: map-get($breakpoints, highres)) { @content; }
28 | }
29 |
30 | @else if $class == highres {
31 | @media (min-width: (map-get($breakpoints, highres) + 1)) { @content; }
32 | }
33 |
34 | @else {
35 | @warn "Breakpoint mixin supports: mobile, tablet, desktop, highres";
36 | }
37 | }
38 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-retrospective-continuous-learning.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Retrospective and continuous learning
3 | category: Projects
4 | ---
5 |
6 | At the end of each sprint the team is conducting a retrospective to know what to:
7 |
8 | 1. **Continue doing**
9 | 2. **Stop doing**
10 | 3. **Try doing**
11 |
12 | This can be covered with the questions:
13 |
14 | * What was supposed to happen?
15 | * What actually happened?
16 | * What worked really well during this project?
17 | * What should we make sure we do again in the future?
18 | * Where did we run into challenges?
19 |
20 | Make sure you outline actionables and discuss with the team how to implement them to foster continuous learning.
21 |
22 | ### Dos and don’ts
23 | **Definitely do**
24 |
25 | * Emphasiye the need for continuous improvement (processes are not set in stone)
26 | * Learn from history
27 | * Take action
28 | * Add it in your project plan
29 | * Be honnest and constructive
30 | * Keep track of past retrospectives
31 |
32 | **Do not**
33 |
34 | * Point fingers
35 | * Use the occasion to vent
36 | * Considering the retrospective a “post-mortem” or “after-action” report rather than an opportunity to plan for improvement
37 | * Suppress feelings
38 | * Include uninvited external members (team only unless invited)
39 |
--------------------------------------------------------------------------------
/_sass/utils/_arrow.scss:
--------------------------------------------------------------------------------
1 | @mixin arrow($position: left, $color: $black, $size: 5px) {
2 | content: '';
3 | position: absolute;
4 | @if $position == top {
5 | border-left: $size solid transparent;
6 | border-top-color: $color;
7 | border-bottom: $size solid $color;
8 | border-right: $size solid transparent;
9 | left: 50%;
10 | top: -$size;
11 | transform: translateX(-50%);
12 | }
13 | @else if $position == right {
14 | border-top: $size solid transparent;
15 | border-right-color: $color;
16 | border-left: $size solid $color;
17 | border-bottom: $size solid transparent;
18 | right: -$size;
19 | top: 50%;
20 | transform: translateY(-50%);
21 | }
22 | @else if $position == bottom {
23 | border-right: $size solid transparent;
24 | border-bottom-color: $color;
25 | border-top: $size solid $color;
26 | border-left: $size solid transparent;
27 | bottom: -$size;
28 | left: 50%;
29 | transform: translateX(-50%);
30 | }
31 | @else {
32 | border-bottom: $size solid transparent;
33 | border-left-color: $color;
34 | border-right: $size solid $color;
35 | border-top: $size solid transparent;
36 | left: -$size;
37 | top: 50%;
38 | transform: translateY(-50%);
39 | }
40 | }
41 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-tools-methodologies-people.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Tools, methodologies & people
3 | category: Company
4 | ---
5 |
6 | The foundation of pretty much anything that we do relies on 3 things; **Tools**, **Processes** & **People**.
7 |
8 | Invariably, when we work on something new (e.g. professionalizing our marketing, or building a DevOps team), we go through the same motions;
9 |
10 | 1. **At first, we rely on people to go out there, get things started and figure it out**. It often is a single person.
11 | 1. **As we understand things better, we start outlining processes**. Ultimately, we want these to be captured in this very playbook, but it often starts as a collection of Hackpad documents.
12 | 1. **The final step is usually to leverage tools to try and automate ourselves out of things**. Sometimes we use existing tools, sometimes we build our own, sometimes we glue a few things together using [Zapier](http://zapier.com).
13 |
14 | There's an obvious incentive to invest into automation & tools over time, and processes as an alternative, rather than people (because being lazy is being smart). Your goal should be to free yourself from manual and repetitive work and design a method for the rest. This not only makes your job easier but ensures that you can share responsibilities or even delegate them.
15 |
--------------------------------------------------------------------------------
/_sass/partials/_helpers.scss:
--------------------------------------------------------------------------------
1 | .grey {
2 | color: $grey;
3 | }
4 |
5 | .color-inherit {
6 | color: inherit;
7 | }
8 |
9 | .small {
10 | @include font-size($small);
11 | }
12 |
13 | .smaller {
14 | @include font-size($smaller);
15 | }
16 |
17 | .thin {
18 | font-weight: 200;
19 | }
20 |
21 | .regular {
22 | @include font-size($regular);
23 | line-height: 160%;
24 | }
25 |
26 | .hidden {
27 | display: none;
28 | }
29 |
30 | .full-width {
31 | box-sizing: border-box;
32 | width: 100%;
33 | }
34 |
35 | .ellipsis {
36 | overflow: hidden;
37 | text-overflow: ellipsis;
38 | white-space: nowrap;
39 | }
40 |
41 | .align-left {
42 | text-align: left;
43 | }
44 |
45 | .align-right {
46 | text-align: right;
47 | }
48 |
49 | .centered {
50 | text-align: center;
51 | }
52 |
53 | .mobile-only {
54 | @include breakpoint(mobile) {
55 | display: block;
56 | }
57 | @include breakpoint(tablet) {
58 | display: none;
59 | }
60 | }
61 |
62 | // Border
63 |
64 | .border-bottom {
65 | border-bottom: 1px solid $line;
66 | }
67 | .border-left {
68 | border-left: 1px solid $line;
69 | }
70 | .border-right {
71 | border-right: 1px solid $line;
72 | }
73 | .border-top {
74 | border-top: 1px solid $line;
75 | }
76 |
77 | // list
78 |
79 | ul.list {
80 | list-style: none;
81 | margin: 0;
82 | padding: 0;
83 | li {
84 | padding: 0;
85 | margin: 0;
86 | }
87 | }
88 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | Jekyll Basics is a simple boilerplate for Jekyll websites with a few (opinionated)
2 | best practices in mind:
3 |
4 | - Multilingual support,
5 | - Proper config with ,
6 | - SASS styling with [egg](https://wiredcraft.github.io/egg/) (a SASS micro-framework),
7 |
8 | ## Install & Run
9 |
10 | 1. Make sure you have Ruby 2.1.0 or higher installed:
11 |
12 | ruby --version
13 |
14 | 2. Install the `github-pages` gem;
15 |
16 | gem install github-pages
17 |
18 | *If that doesn't work for you, try the [GitHub help](https://help.github.com/articles/setting-up-your-github-pages-site-locally-with-jekyll/).*
19 |
20 | 3. Run the site:
21 |
22 | make serve
23 |
24 | Then go to http://localhost:4000. This will overload the Jekyll configuration (`_config.yml`) with the dev settings (`_config-dev.yml`) and make sure it uses the increment build option.
25 |
26 | *For more details, see the `Makefile`.*
27 |
28 | ## CMS
29 |
30 | Jekyll Basics comes with [Jekyll+](https://github.com/Wiredcraft/jekyllplus) set up by default.
31 |
32 | If you're on GitHub pages, you should be able to show the edit button by appending `?jekyllplus=true` to the URL. For example: https://wiredcraft.github.io/jekyll-basics/?jekyllplus=true
33 |
34 | If needed, you can set it up manually at the end of the `_config.yml` file by setting
35 | up the `jekyllplus` variable:
36 |
37 | jekyllplus: Wiredcraft/jekyll-basics/master
38 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-pitching-our-company.md:
--------------------------------------------------------------------------------
1 | ---
2 | sticky: true
3 | title: Pitching our company
4 | category: Business
5 | ---
6 |
7 | If and when you have to pitch our team, you'll probably do giving increasing levels of details:
8 |
9 | 1. In a nutshell, **"We're a digital product agency"**,
10 | 1. More details **"We build web and mobile apps, and provide a range of related services including data science, DevOps, design and strategy"**,
11 | 1. Concrete examples and bragging.**"We've built things like the software that ran the Myanmar elections with USAID to rebuilding Starbucks' entire digital strategy for the Chinese market (mobile apps, websites, payment gateways...)"**.
12 |
13 | After this you'll need to adapt your pitch to the audience:
14 |
15 | - If you're talking to an engineer, you'll want to talk about the tech we're using (e.g. Docker, Node.js, Golang).
16 | - If your audience is more design-oriented, talk about our design culture (e.g. [How we design products](https://wiredcraft.com/blog/how-we-design-products/)).
17 | - In any case, try and brag about the type of clients we've worked with (e.g. Apple, Starbucks, the UN) and the scale at which we've done so (e.g. 35M voters in Myanmar, business intelligence for all of Apple's manufacturing).
18 |
19 | Ultimately, if you run into a question or inquiry more than a couple times, it would be a good idea to have somebody write a post about it. **Our blog should be the best FAQ for prospective clients (or recruits)**.
20 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-how-to-generate-leads.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: How to generate leads?
3 | category: Business
4 | ---
5 |
6 | **tl;dr: Meet people, get introduced or recommended and invest in marketing. Leads will follow.**
7 |
8 | Business is one big funnel, starting with generating leads. Leads come from many different places:
9 |
10 | - **Connections**: overall the most common way we end up getting work.
11 | - **Referrals & Intros**: we sometimes ask for them and sometimes our clients or connections offer them on their own.
12 | - **Content (social media, blog posts, newsletter)**: this usually works better for recruitment but also yields occasional business leads.
13 | - **Meetups**: meetups and conferences are a great way to put our team in the spotlight (which is why we organize so many of them). Same as for content, it chiefly generates recruitment leads, but still brings us some business.
14 | - **Cold contacting**: it sometimes happen that we actively reach out to a specific team/organization. These usually convert poorly though and/or take time.
15 | - **Vendor databases**: being listed on some of the vendor databases (e.g. World Bank or UN), we receive RFPs once in a while.
16 | - ...
17 |
18 | Ultimately, we want to move as much as possible towards inbound leads (e.g. leads coming from our content or reputation), as these tend to scale better than outbound business development (e.g. cold emailing). However, meeting people (through events, introductions, etc.) will most certainly remain a core component of our success.
19 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-loosely-coupled-tightly-aligned.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Loosely coupled, tightly aligned
3 | category: Company
4 | ---
5 |
6 | As mentioned [before](./Culture), many aspects of our organization naturally adopt a "loosely coupled, tightly aligned" approach. For example;
7 |
8 | - **Small, independent and agile teams**.
10 | - **Service oriented software architectures**. [We tend to prefer building apps with separate front-end and backend codebases](http://devo.ps/blog/farewell-to-regular-web-development-approaches/), combining micro-services in the backend (rather than a monolithic API) and modular, component-based front-ends.
11 | - **Ad-hoc and flexible processes**. This very playbook outlines high level concepts for understanding our approach to the main activities of our organization. While we have core values, these activities are ran independently and subject to frequent change independently of each others.
12 |
13 | It's important that you keep this concept in mind through your work and interactions with others on the team. In particular, be aware that things are not set in stone; **if you see a way to improve or fix things, just speak out**. In most cases, things are set a certain way because it was good enough until now.
14 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-contract-numbering.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Contract numbering scheme
3 | category: Business
4 | ---
5 |
6 | In order to keep the overview over our contracts and being able to consolidate them across different platforms, we are implementing the following contracting scheme.
7 |
8 | ### How do we name and number the contracts?
9 |
10 | We are following this pattern:
11 |
12 | `Location - Client Name - Opportunity - Type of Contract - Date [YYMMDD]`
13 |
14 | For example:
15 |
16 | `S-BASF-3-SOW-170626`
17 |
18 | Which means:
19 |
20 | * `S` - Contract for Shanghai
21 | * `BASF` - The client is BASF
22 | * `1` - Third contract with the client
23 | * `SOW` - This is a SOW document
24 | * `170626` - It was signed on the 26 of June 2017
25 |
26 | See below for more information on each item.
27 |
28 | ### Numbering items
29 |
30 | 1. Location
31 |
32 | Acronym | Definition
33 | ---- | ----
34 | S | Shanghai
35 | G | Global
36 | B | Berlin
37 |
38 | 2. Client Name
39 | 3. Opportunity number
40 | 4. Contract naming
41 |
42 | Acronym | Definition
43 | ----- | -----
44 | NDA | Non Disclosure agreement
45 | MSA | Master Service Agreement
46 | SOW | Statement of Work
47 | CO | Change Order
48 |
49 | 5. Date (date of signature of client) - Format `YYMMDD`
50 |
51 | ### Where do we add the contract number?
52 |
53 | We need to have a contract number scheme on all related tools and documents:
54 |
55 | * Wave - add in contract number field
56 | * Google docs- contract number in footer
57 | * Github issue - contract number in title
58 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-product-design.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Product design
3 | category: Design
4 | ---
5 |
6 | **[Our product design process](https://wiredcraft.com/blog/how-we-design-products/) helps us improve the odds of [making something people want](http://paulgraham.com/good.html) by focusing on the idea/validation feedback loop**. We apply this process to most of what we do; it helps us design marketing experiments, write business proposals, shape our company strategy...
7 |
8 | We took inspiration from [Google Ventures' Design Sprint](http://www.gv.com/sprint/), going iteratively through 5 steps;
9 |
10 | - **[Understand](https://wiredcraft.com/blog/how-we-design-products/#understand)**: establish the context and problem (e.g. "What data do we have?", "What pain are we solving?"), list our assumptions and define how we intend to validate them.
11 | - **[Diverge](https://wiredcraft.com/blog/how-we-design-products/#diverge)**: generate multiple (potentially conflictual) solutions to solve the problem at hand.
12 | - **[Converge](https://wiredcraft.com/blog/how-we-design-products/#converge)**: align the team around one approach (e.g. a single user flow/storyboard).
13 | - **[Prototype](https://wiredcraft.com/blog/how-we-design-products/#prototype)**: quickly build a prototype we can test.
14 | - **[Validate](https://wiredcraft.com/blog/how-we-design-products/#validate)**: test the prototype, usually with actual users outside of our team, to learn what works and what doesn’t.
15 |
16 | Each cycle helps us validate and invalidate our assumptions, and get us one step closer to understanding what works.
17 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-employee-pipeline.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: The employee pipeline
3 | category: Employees
4 | sticky: true
5 | ---
6 |
7 | Employees, not unlike clients, go through a simple pipeline;
8 |
9 | 1. **Audience**; at this stage, potential recruits may have heard of us from a blog post, from an event we organized or were referred from a friend. Sometimes they even are clients or partners (although we have a strict "no poaching" policy, meaning they need to reach out to us on their own).
10 | 2. **Applicants** can [apply to a specific position through our website](https://wiredcraft.com/about/#jobs). They are either organically coming to it (after reading one of our post or seeing one of our job ads) or are referred to it by one of our employees.
11 | 3. **Interviewees** are invited to pick a time to come over to the office and meet with at least one senior (usually from the team the interviewee would join). We then evaluate their skills with a concrete exercise/task and decide whether or not we want to move further with an offer.
12 | 4. **Employees**. Once they accepted our offer, we bring them on-board (usually a Friday). We try and make this first day memorable and as smooth as possible. We focus on employee happiness (regular feedback, clear performance and goal tracking, incentives, team building...) to ensure people love their job.
13 | 5. **Alumnus**. Employees leave at some point. While our goal is to make sure this happens as rarely as possible, we do pride ourselves into maintaining good relations with past colleagues. We make sure we try and learn from their departure, and keep close through our [[alumni network]].
14 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-sales-101.md:
--------------------------------------------------------------------------------
1 | ---
2 | sticky: true
3 | title: Sales 101
4 | category: Business
5 | ---
6 |
7 | We're mostly nerds, and nerds tend to think that to be good at sales you have to be naturally extroverted and sociable. This is false. Being good at sales takes only a few things:
8 |
9 | - **Listen**: it's not about you, it's about the client. Don't regurgitate your pitch to people. Shut up, let them talk, ask questions, and try to genuinely understand what they need and how you can help.
10 | - **Be trustworthy**: the best kind of clients (the only kind we want) are people who want to work with us because they know we'll do a great job. If you have to force somebody into a deal, you'll regret it later. Establishing trust with your connections should be your top priority, because nobody buys from someone they don't know.
11 | - **Be helpful**: the best way to establish trust and get people on your side is to be genuinely helpful to them. "Pay it forward," or help people with your expertise and resources without necessarily expecting anything in return. This means passing along references and opportunities, rather than trying to catch every single possible opportunity.
12 | - **Move fast**: speed is a huge factor in selling. Send emails right after a meeting with a clear summary of your interaction along with next steps. If you promised an introduction do it right away. If a client wants to do business with you, get an estimate as fast as possible to him. Once that's done, get the contract signed and start working.
13 |
14 | There's nothing more to it: **meet people, listen, establish trust, be genuinely helpful and move fast**.
15 |
--------------------------------------------------------------------------------
/_sass/custom/_search.scss:
--------------------------------------------------------------------------------
1 | .search-wrapper {
2 | position: relative;
3 | width: 100%;
4 | svg {
5 | fill: $grey;
6 | height: $space;
7 | position: absolute;
8 | right: $space/2;
9 | top: 50%;
10 | transform: translateY(-50%);
11 | width: $space;
12 | }
13 | .search {
14 | padding-right: 1.5*$space;
15 | &:focus {
16 | & + .search-results {
17 | display: block;
18 | }
19 | }
20 | }
21 | .search-results {
22 | background: #FFF;
23 | border: 1px solid $line;
24 | border-radius: $radius;
25 | box-shadow: $shadow;
26 | display: none;
27 | position: absolute;
28 | width: 100%;
29 | &:hover {
30 | display: block;
31 | }
32 | ul {
33 | list-style: none;
34 | margin: 0;
35 | padding: 0;
36 | li {
37 | padding: 0;
38 | margin: 0;
39 | &:first-child {
40 | a {
41 | border-radius: $radius $radius 0 0;
42 | }
43 | }
44 | &:last {
45 | a {
46 | border-radius: 0 0 $radius $radius;
47 | }
48 | }
49 | a {
50 | color: inherit;
51 | display: block;
52 | padding: $space/2 1.5*$space/2;
53 | &:hover {
54 | background: $light;
55 | text-decoration: none;
56 | }
57 | }
58 | h3 {
59 | font-size: inherit;
60 | margin-bottom: 0;
61 | }
62 | p {
63 | margin-bottom: 0;
64 | }
65 | }
66 | }
67 | .default,
68 | .empty {
69 | color: $grey;
70 | margin: 0;
71 | padding: $space/2 1.5*$space/2;
72 | }
73 | }
74 | }
75 |
--------------------------------------------------------------------------------
/_sass/partials/_switch.scss:
--------------------------------------------------------------------------------
1 | .switch {
2 | display: block;
3 | height: map-get($switch, size) + 2*map-get($switch, padding);
4 | position: relative;
5 | width: map-get($switch, length) + 2*map-get($switch, padding);
6 | &:active {
7 | border-color: $blue;
8 | border-radius: 2*map-get($switch, size);
9 | box-shadow: 0 0 0 2px rgba($blue, 0.2);
10 | outline: none;
11 | }
12 | input {
13 | opacity: 0;
14 | &:checked+.slider {
15 | background: $blue;
16 | }
17 | &:checked+.slider span {
18 | transform: translateX(map-get($switch, length) - map-get($switch, size));
19 | }
20 | }
21 | .slider {
22 | background: $line;
23 | border-radius: 2*map-get($switch, size);
24 | bottom: 0;
25 | cursor: pointer;
26 | left: 0;
27 | position: absolute;
28 | right: 0;
29 | top: 0;
30 | transition-duration: $ease;
31 | span {
32 | background: #FFF;
33 | border-radius: 50%;
34 | bottom: map-get($switch, padding);
35 | height: map-get($switch, size);
36 | left: map-get($switch, padding);
37 | position: absolute;
38 | width: map-get($switch, size);
39 | transition-duration: $ease;
40 | &:after {
41 | content: '';
42 | border-radius: 50%;
43 | background: $green;
44 | left: -9px;
45 | opacity: 0;
46 | position: absolute;
47 | top: -9px;
48 | -ms-transform: scale(0);
49 | -webkit-transform: scale(0);
50 | transform: scale(0);
51 | height: map-get($switch, size)*1.6;
52 | width: map-get($switch, size)*1.6;
53 | }
54 | }
55 | }
56 | & + label {
57 | cursor: pointer;
58 | display: inline-block;
59 | }
60 | }
61 |
--------------------------------------------------------------------------------
/_layouts/front.html:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | ---
4 |
5 | {% include utils/i18n.liquid %}
6 |
7 |
8 |
9 |
42 |
43 |
--------------------------------------------------------------------------------
/sitemap.xml:
--------------------------------------------------------------------------------
1 | ---
2 | layout: null
3 | ---
4 |
5 |
6 | {% for collection in site.collections %}
7 | {% if site.lang.size > 1 %}{% assign docs = site[collection.label] | where: 'lang', site.lang.first %}
8 | {% else %}{% assign docs = site[collection.label] %}{% endif %}
9 | {% for doc in docs %}
10 |
11 | {{ site.url }}{{ site.baseurl }}{{ doc.url }}
12 | {{ site.time | date_to_xmlschema }}
13 | weekly
14 | 0.5
15 | {% if site.lang.size > 1 %}
16 | {% for translation_lang in site.lang %}
17 |
18 | {% endfor %}
19 | {% endif %}
20 |
21 | {% endfor %}
22 | {% endfor %}
23 | {% if site.lang.size > 1 %}{% assign docs = site.pages | where: 'lang', site.lang.first %}
24 | {% else %}{% assign docs = site.pages %}{% endif %}
25 | {% for doc in docs %}
26 |
27 | {{ site.url }}{{ site.baseurl }}{{ doc.url }}
28 | {{ site.time | date_to_xmlschema }}
29 | weekly
30 | 0.3
31 | {% if site.lang.size > 1 %}
32 | {% for translation_lang in site.lang %}
33 |
34 | {% endfor %}
35 | {% endif %}
36 |
37 | {% endfor %}
38 |
39 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-projects-using-docker-containers.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Projects using Docker containers
3 | category: DevOps
4 | ---
5 |
6 | Docker containers offer a wide range of benefit, allowing to QA, deploy with the exact same versions on dev / staging / prod.
7 |
8 | Containers need to be built, hosted and shared between the various environments and benefit from having a centralized architecture.
9 |
10 | ## Requirements
11 |
12 | You need the following set and available:
13 |
14 | - Project's Pipelines instance + admin access (see [[Pipelines]])
15 | - A server capable of running Docker containers
16 |
17 | ## Steps
18 |
19 | - Add the project to Wiredcraft Docker registry:
20 | - Create a project
21 | - Create users for that project
22 | - Update permissions of current users to access the new project
23 | - (optional) Set replication to China
24 | - Configure the project's Pipelines:
25 | - (optional) Add secret file to read data from the vault
26 | - Add the pipelines to build the containers
27 | - Add the pipelines to deploy the containers on the remote servers
28 | - (optional) Add Webhook support for auto-build / auto-deploy
29 |
30 | Sit down and relax (or start coding!); you can now enjoy your platform being updated automatically (via webhook) or triggered manually by a simple button.
31 |
32 | ## Sample pipelines
33 |
34 | TBD
35 |
36 | ## Extra notes to include
37 |
38 | - `{cust}-build`: R/W to registry US - `{cust}` to be replaced by the real customer name
39 | - `{cust}-deploy`: R/O from registry US + CN
40 | - `sync`: R/W on all projects - used only for replication
41 | - `{cust}` should also match the pipelines name
42 | - `https://pipelines-{cust}.service.wiredcraft.com/keys`: must be included to the `wcladmin` user (or other user)
43 |
44 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-business-resources.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Business resources
3 | category: Business
4 | ---
5 |
6 | - **Book › [Hyper Sales Growth](http://www.amazon.com/Hyper-Sales-Growth-Street-Proven-Profitably-ebook/dp/B00J2BBO26)**; a great read, with many concise, practical advice on sales and sales teams. A must read. Also [check the author's website](http://www.jackdaly.net/).
7 | - **Book › [How to Win Friends & Influence People](http://www.amazon.com/How-Win-Friends-Influence-People/dp/0671027034)**
8 | - **Blog post › [Five ways to build a $100 million business](http://christophjanz.blogspot.com/2014/10/five-ways-to-build-100-million-business.html)**
9 | - **Book › [Selling 101](http://www.amazon.com/Selling-101-Every-Successful-Professional/dp/0785264817)**
10 | - **Video › [Lecture 19 - Sales and Marketing; How to Talk to Investors (Tyler Bosmeny; YC Partners)](https://clip.mn/video/yt-SHAh6WKBgiE)**; part of the ["How to start a startup" video series from YC](http://startupclass.samaltman.com/). Presentation from a startup founder of the sales funnel and advice on how to get sales off the ground.
11 | - **Blog post › [Systematizing Sales With Software And Processes](https://training.kalzumeus.com/newsletters/archive/sales_automation)**; a post from patio11 (aka Kalzumeus) about the principles of sales automation (deal tracking, follow up, upsales...).
12 | - **Blog post › [A Technical Founder’s Notes on Sales Team Management](https://medium.com/@kwindla/a-technical-founder-s-notes-on-sales-team-management-60e1a93d4648#.bt7fchius)**; what to expect when building a sales team.
13 | - **Blog post › [The Zero B.S. Method To Recruiting A Killer Sales Force](a16z.com/2015/09/16/the-zero-b-s-method-to-recruiting-a-killer-sales-force/)**
14 | - **Podcast › [The Salesman](http://salesman.red/category/podcast/)**
15 |
--------------------------------------------------------------------------------
/_sass/partials/_tooltip.scss:
--------------------------------------------------------------------------------
1 | @if index($partials, tooltip) {
2 | .tooltip,
3 | .tooltip-bottom,
4 | .tooltip-left,
5 | .tooltip-right,
6 | .tooltip-top {
7 | position: relative;
8 | > .text {
9 | background: $black;
10 | border-radius: $radius - 1;
11 | color: #FFF;
12 | @include font-size($small);
13 | line-height: 160%;
14 | opacity: 0;
15 | padding: $space/4 1.5*$space/4;
16 | position: absolute;
17 | text-align: center;
18 | transition-property: opacity, transform;
19 | transition-duration: $ease;
20 | // transform: translate(0, 0);
21 | visibility: hidden;
22 | white-space: nowrap;
23 | width: auto;
24 | z-index: 999;
25 | }
26 | &:hover > .text {
27 | opacity: 1;
28 | visibility: visible;
29 | }
30 | }
31 | .tooltip,
32 | .tooltip-top {
33 | > .text {
34 | bottom: 100%;
35 | left: 50%;
36 | margin-bottom: 5px;
37 | transform: translateX(-50%);
38 | &:after {
39 | @include arrow(bottom, $black);
40 | }
41 | }
42 | }
43 | .tooltip-bottom {
44 | > .text {
45 | left: 50%;
46 | margin-top: 5px;
47 | top: 100%;
48 | transform: translateX(-50%);
49 | &:after {
50 | @include arrow(top, $black);
51 | }
52 | }
53 | }
54 | .tooltip-left {
55 | > .text {
56 | margin-right: 5px;
57 | right: 100%;
58 | top: 50%;
59 | transform: translateY(-50%);
60 | &:after {
61 | @include arrow(right, $black);
62 | }
63 | }
64 | }
65 | .tooltip-right {
66 | > .text {
67 | left: 100%;
68 | margin-left: 5px;
69 | top: 50%;
70 | transform: translateY(-50%);
71 | &:after {
72 | @include arrow(left, $black);
73 | }
74 | }
75 | }
76 | }
77 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-project-lifecycle.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Project lifecycle
3 | category: Projects
4 | weight: -10
5 | ---
6 |
7 | Following on the [Product design](http://playbook.wiredcraft.com/article/product-design/), the products goes through the following 3 steps:
8 |
9 | 1. **Kick-off**: through an initial meeting we solidify a common understanding of the work which leads to: a refined strategy, fleshed out [personas, core user stories]http://playbook.wiredcraft.com/article/user-story/) and tasks.
10 | 3. **Iterative development**: we follow [Scrumban methodology](https://blog.assembla.com/AssemblaBlog/tabid/12618/bid/87904/Scrum-Kanban-ScrumBan-an-Easy-Scrum-Upgrade.aspx) which allows us to avoid *big design up front* in favor of *planning on demand*. We deliveries subset of issues (previously agreed on) during sprints which are organized in milestones.
11 | 4. **Conclusion**: following the succesful delivery of the deliverables we conduct a post-mortem meeting. All team members are invited to retrospect on the past project. The goal is to improve future iterations and highlight lessons learned.
12 |
13 | ### Dos and don’ts
14 | **Definitely do**
15 |
16 | * [Timeboxed meetings](http://www.boost.co.nz/blog/2014/09/the-joy-of-timeboxed-meetings/)
17 | * Ask for feedback often
18 | * Check-in regularly
19 | * Team members doing the work support the effort (bottom-up approach)
20 | * Call ad-hoc meetings when necessary
21 | * Host weekly stand up with all team members (in person or online)
22 |
23 | **Do not**
24 |
25 | * Work in silo
26 | * Communicate in private messages ([transperency over obscurity](http://playbook.wiredcraft.com/Projects/Dealing-with-projects.html))
27 | * Follow unwavering top-down decisions
28 | * Add tasks as sprints are ongoing
29 | * Execute without leveraging [Tools, Processes & People](http://playbook.wiredcraft.com/Company/tools-methodologies-people.html)
30 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-working-with-your-colleagues.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Working with your colleagues
3 | category: Company
4 | date: 2018-10-01
5 | ---
6 |
7 | **We believe in working online as much as possible, mostly because it makes things accessible and inclusive**:
8 |
9 | - Face-to-face meetings and conference calls are sometimes necessary, but they tend to be inefficient, requiring all participants to be available at the same time. We prefer working asynchronously, making it easy for people to take part if and when they want.
10 | - Digital content can survive and evolve into something ultimately useful. [Post-its and fancy paper prototypes turn stale](https://wiredcraft.com/blog/human-centered-design-is-a-waste-of-paper/). Notes captured in a Hackpad have at least a shot at being recycled down the line.
11 | - Finally, when you work online, people have an easier time to get involved into things that they weren't specifically invited to. It is surprising how often one of us jump into a discussion on GitHub that they were notified of on Slack.
12 |
13 | A few tools we use across the whole team;
14 |
15 | - We use **[Slack](https://wiredcraft.slack.com)** for most interactions. It also integrates with many 3rd party services we use and provides a ton of useful notifications (e.g. new issue on a GitHub issue).
16 | - **[GitHub](https://github.com/Wiredcraft)** is where we [track pretty much everything](https://wiredcraft.com/blog/github-for-everything/); recruitment, marketing, development, operations...
17 | - **Google apps** (Gmail & Google Docs mostly) for email, documents, spreadsheets, forms...
18 | - Often times, we will draft documents on **[Dropbox Paper](https://paper.dropbox.com/)** (e.g. client proposal or SCRUM notes).
19 |
20 | We also use [WeChat](http://www.wechat.com/en/), mostly because it works great both in China and abroad, as well as [InVision](http://www.invisionapp.com/) to share our design work and collect feedback.
21 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-reimbursement.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Expenses & Reimbursements
3 | category: Employees
4 | ---
5 |
6 | ## What is a reimbursement
7 |
8 | Overall, our approach for these is the same as everything else; we assume you behave responsibly and expect you handle company expenses in the same way you would with your own money.
9 |
10 | Here are few guidelines;
11 |
12 | - **For any expense, you have to provide a fapiao (for China) or official invoice**. Reach out to operations; see below for the reimbursement steps.
13 | - **Small related expenses** (e.g. cab ride) are systematically reimbursed, assuming they're in a reasonable range (maximum of 200 RMB/30 USD/30 EUR).
14 | - **Larger expenses** (e.g. business trip to another city, conference tickets for multiple team members) require confirmation from your team leader. Create an issue in the appropriate repo (e.g. `Wiredcraft/business` for a business trip or `Wiredcraft/team` for a conference) with the estimated budget and assign it to him.
15 | - **Team leaders have access to a discretionary budget** for their department they can use for things like team lunches, books, online courses. Larger expenses (above 600 RMB/100 USD/100 EUR) need approval from the Operations team.
16 | - **Always ask your team leader if you think the company should reimburse something**. Often, the reason why we haven't offered to cover an expense is just that we're not aware of it.
17 |
18 | ## Reimbursement steps
19 |
20 | In order to get a reimbursement you need to follow these steps:
21 |
22 | * **Step 1**: request the official fapiao(s) (physical and digital are both acceptable) related to the expense.
23 | * **Step 2**: fill out the [reimbursement form](https://goo.gl/forms/FHczq6zs1hpCuw303).
24 | * **Step 3**: submit the fapiao(s) to the Operations team.
25 |
26 | **You'll be reimbursed at the end of the month along with the payroll**. If you need to be reimbursed before that, mention it in the comment section of the reimbursement form.
27 |
--------------------------------------------------------------------------------
/_layouts/page.html:
--------------------------------------------------------------------------------
1 | ---
2 | layout: default
3 | ---
4 |
5 | {% include utils/i18n.liquid %}
6 |
7 |
8 |
46 |
47 |
--------------------------------------------------------------------------------
/_sass/partials/_dropdown.scss:
--------------------------------------------------------------------------------
1 | @if index($partials, dropdown) {
2 | .dropdown {
3 | position: relative;
4 | > *:first-child {
5 | cursor: pointer;
6 | }
7 | .options {
8 | background: #FFF;
9 | border: 1px solid $line-2;
10 | border-radius: $radius;
11 | box-shadow: $shadow-1;
12 | box-sizing: border-box;
13 | display: block;
14 | margin-top: -$space/2;
15 | opacity: 0;
16 | position: absolute;
17 | top: 100%;
18 | transition-property: opacity, margin;
19 | transition-duration: $ease;
20 | visibility: hidden;
21 | z-index: 999;
22 | }
23 | > *.active:first-child + .options,
24 | &.active .options,
25 | .options:hover,
26 | &.hover:hover .options {
27 | opacity: 1;
28 | margin-top: 0;
29 | visibility: visible;
30 | }
31 |
32 | &.menu {
33 | .options {
34 | padding: $space/6 0;
35 | .option {
36 | background: rgba($light, 0);
37 | display: block;
38 | color: inherit;
39 | cursor: pointer;
40 | @include font-size($smaller);
41 | line-height: 160%;
42 | padding: $space/8 $space/2;
43 | margin: $space/6 0;
44 | transition-property: background;
45 | transition-duration: $ease;
46 | white-space: nowrap;
47 | &:hover {
48 | background: $light;
49 | text-decoration: none;
50 | }
51 | &.danger:hover {
52 | color: $red;
53 | }
54 | a,
55 | a:hover {
56 | color: inherit;
57 | display: block;
58 | font-size: inherit;
59 | line-height: inherit;
60 | text-decoration: inherit;
61 | }
62 | }
63 | > hr {
64 | border: 0;
65 | border-top: 1px solid $line-2;
66 | margin: $space/6 0;
67 | }
68 | }
69 | }
70 | }
71 | }
72 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-how-to-schedule-and-produce-blog-content.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: How to schedule and produce blog content?
3 | category: Marketing
4 | ---
5 |
6 | [Blog posts are at the core of our marketing strategy](/Several-mediums); they're the main asset driving traffic to our website and a key element when pitching clients. Getting a consistent stream of blog posts from our creatives and developers is very challenging, but crucial to our activity.
7 |
8 | We host weekly editorial meetings as a marketing team to coordinate our posts and ensure the process is moving smoothly.
9 |
10 |
11 | - We keep a [schedule of upcoming blog posts in a Google Spreadsheet](https://docs.google.com/spreadsheets/d/1TSeMy2K2HKRB_GkKQqXQogH8I0Pt_5VPeBkBlrt5qhg/edit?usp=sharing) and rigorously map things out in advance.
12 | - Then we spend some time building a list of interesting topics well in advance to map out a good variety for publishing.
13 | - Finding contributors is next. The trick here is finding colleagues who have done work relevant to the topic and are interested in sharing their thoughts and experience.
14 | - At every meeting, we'll follow this **agenda:**
15 | - _For that week (1 week before posting):_ making sure posts are ready, scheduling last touches/polish and scheduling the sharing/PR/outreach campaign (for example, if we mention a 3rd party, maybe reach out to them).
16 | - _For the next week (2 weeks before posting):_ checking on progress and making sure we'll meet the deadline. Potentially figure out who on the team needs/can help.
17 | - _For the week after (3 weeks before posting):_ picking a topic and identifying people on the team to be contributors.
18 |
19 |
20 | If you've never written a blog post and don't know where to start, I recommend you read ["Blogging in 3 steps"](https://wiredcraft.com/blog/blogging-in-3-steps/). For making your blog content more interesting, check ["Company Blogging Done Best (Or, Make Sure It's Not A Snoozefest)"](https://wiredcraft.com/blog/Make-Your-Company-Blog-Awesome/)
21 |
--------------------------------------------------------------------------------
/_sass/utils/_variables.scss:
--------------------------------------------------------------------------------
1 | /* Colors */
2 |
3 | $black: #1b2733 !default;
4 | $blue: #0070E0 !default;
5 | $purple: #9933CC !default;
6 | $green: #66CC33 !default;
7 | $orange: #ff8e21 !default;
8 | $red: #CC3333 !default;
9 | $silver: #DDDDDD !default;
10 | $yellow: #ffe28f !default;
11 |
12 | $background: #FFF !default;
13 | $primary: $blue !default;
14 |
15 | $light: #f7f9fa !default;
16 |
17 | $grey: #637282 !default;
18 | $grey-2: rgba($grey, 0.6);
19 | $grey-3: rgba($grey, 0.3);
20 |
21 | $line: #c1c7cd !default;
22 | $line-1: $line;
23 | $line-2: rgba($line, 0.6) !default;
24 | $line-3: rgba($line, 0.3) !default;
25 |
26 | /* Sizes */
27 |
28 | $headline-1: 48 !default;
29 | $headline-2: 32 !default;
30 | $headline-3: 18 !default;
31 | $large: 24 !default;
32 | $larger: 18 !default;
33 | $regular: 16 !default;
34 | $smaller: 14 !default;
35 | $small: 12 !default;
36 |
37 | /* Fonts */
38 |
39 | $body: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol' !default;
40 | $headline: $body !default;
41 | $code: 'SFMono-Regular', Consolas, 'Liberation Mono', Menlo, Courier, monospace !default;
42 |
43 | /* Misc */
44 |
45 | $ease: 0.2s !default;
46 | $space: 24px !default;
47 | $radius: 4px !default;
48 | $shadow-0: rgba(0, 0, 0, 0) 0 1px 0 0 !default;
49 | $shadow: rgba(0, 0, 0, 0.1) 0 1px 4px 0 !default;
50 | $shadow-1: $shadow;
51 | $shadow-2: rgba(0, 0, 0, 0.3) 0 1px 8px 0 !default;
52 | $hover: rgba(0, 0, 0, 0.2) 0 1px 10px 0 !default;
53 | $container: 960px !default;
54 |
55 | /* Responsive */
56 |
57 | $breakpoints: (
58 | tablet: 640px,
59 | desktop: 1024px,
60 | highres: 1280px
61 | ) !default;
62 |
63 | /* Switch */
64 |
65 | $switch: (
66 | size: 1.5*$space/2,
67 | length: 5*$space/3,
68 | padding: 2px
69 | ) !default;
70 |
71 | /* Partials */
72 |
73 | $partials: (
74 | base,
75 | button,
76 | card,
77 | dropdown,
78 | form,
79 | layout,
80 | modal,
81 | notification,
82 | tooltip
83 | ) !default;
84 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-core-design-principles.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Core design principles
3 | category: Design
4 | ---
5 |
6 | We are by no means assuming design can be reduced to a few tricks and guidelines, but the 4 principles below are key to our design approach;
7 |
8 | - **Be deliberate**. Meaning & function trump aesthetics, always. Design things for their use and intent, not because they look good or help balance your composition.
9 | - **Less is more**. In the [words of Antoine de Saint-Exupéry](www.brainyquote.com/quotes/quotes/a/antoinedes121910.html): "perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away". When challenged, you should be able to make up a rational case for anything that you designed1.
10 | - **Design for the common and build patterns**. Don't start designing things for special cases like landing pages; you want to focus first on the most commonly used features, and from there identify patterns that you can apply systematically to the rest of your design. Fight hard against any modification or addition to these patterns as you work your way up to more specific use cases (*aka* [KISS](https://en.wikipedia.org/wiki/KISS_principle)).
11 | - **Focus on proportions, layout, colors & typography**. Balance elements of your designs with the same proportions and avoid designing for pixel perfect situations (that's a rare luxury with digital mediums). Obsess about finding (and stealing2) great colors and typography, they make the difference between good and great.
12 |
13 | 1: this doesn't mean that you should justify everything and anything you do in advance, you have to get stuff done after all. But when challenged about one of your choices, you need to be able to back it up.
14 | 2: there are many resources a couple Google searches away: [Adobe Color](https://color.adobe.com/), [Coolors](https://coolors.co/), [Font Pair](http://fontpair.co/), [Google Web Fonts Typographic Project](https://femmebot.github.io/google-type/)...
15 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-execute.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Execute (kickoff and sprints)
3 | category: Projects
4 | ---
5 |
6 | The project goes through several sprints iterations which will follow the common structure.
7 |
8 | ### How to plan sprints
9 |
10 | Each sprint should start with the following.
11 |
12 | 1. Discuss and set a **goal**
13 | 2. Review and Assign **user story**
14 | 3. Estimate the fitting **effort**
15 | 4. Assign issues to a specific **milestone**
16 |
17 | ### Sprints meetings
18 |
19 | The following meetings take place during the sprints.
20 |
21 | * **Sprint planning**: kicking off the sprint(s).
22 | * **Daily stand-up**: general daily status meeting (details are discussed outside of this meeting).
23 | * **Sprint review**: showcase the work of the team through a demo and celebrate accomplishments
24 | * **Post mortem**: understand what worked well and what did not.
25 |
26 | ### How to properly kick-off (Sprint 0)
27 |
28 | The kick-off sprint will prepare the upcoming developments.
29 |
30 | * **Everybody** should attend
31 | * Present the **personas** and **user story**
32 | * Define the **product backlog** which will list most if not all of the tasks for the upcoming issues
33 | * Define clearly the **goals**
34 | * Schedule the **milestones**
35 | * Outline the **roles**
36 | * *Product backlog*: the main owner of the product
37 | * *Scrum master*: handling scrums and keep things on track
38 | * *Development team*: outline skills of each
39 |
40 | ### Dos and don’ts
41 | **Definitely do**
42 |
43 | * Keep the sprints duration consistent
44 | * Always focus on the current sprint planning
45 | * Outline low hanging fruits for each sprint
46 | * Plan with some leeway (add unplanned time and corporate overhead)
47 | * Allow team members to make decisions
48 |
49 | **Do not**
50 |
51 | * Plan all sprints ahead
52 | * Add additional taks in an ongoing sprint
53 | * Do not schedule a milestone to finish on a Thursday or Friday (avoid weekend support)
54 | * Do not skip daily stand-up meetings
55 | * Make estimates or commitments on team's behalf
56 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-remote-work-and-sick-leave.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Working from home, Remote work & Sick leave
3 | category: Employees
4 | ---
5 |
6 | As with everything else, we assume our team members behave responsibly. We do however ask that you submit a request in [Brease](http://brease.io/)1 to keep track of the following things;
7 |
8 | - **Work from home**; if you want to spend a day working outside of the office. Remember that things are a lot easier when the team can meet face to face (e.g. SCRUM). Try to not to exceed max. 10 days / month.
9 |
10 | - **Remote work**; if you plan on spending more than 2 consecutive days outside of the office, you'll need approval from your team leader. We allow certain employees to be full time remote2, this is however on a case per case basis. If you want to move out of our main locations but still want to work remotely with us, just tallk to your team leader. When you're working remotely, make sure you have a reliable connection, that you're connected on Slack at all times and that you join SCRUM meetings and other discussions or meetings. We expect you to be proactive if you're stuck or if you're not assigned to any task.
11 | - **Sick leave**; if you're sick or feeling unwell, add a request on brease.io and make sure your team is aware of it. Don't forget to also let the Operations team and your manager know, what the expected duration of your absence will be.
12 |
13 | Regulation for the German office:
14 | A doctors’ certificate must be handed in latest on the third day of sickness / absence.
15 | Example:
16 | If you get sick on a Monday, you need to have a sick leave certificate on Wednesday; if you get sick on a Thursday, then you have time to hand it in until Monday.
17 |
18 |
19 | 1: Log in Brease with your Slack account. Brease is developed internally at Wiredcraft, so let us know in #brease on Slack if we can improve it.
20 |
21 | 2: For remote workers, we usually insist on having them coming into the office at least once a month when possible, especially for team buildings.
22 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-our-sales-workflow.md:
--------------------------------------------------------------------------------
1 | ---
2 | sticky: true
3 | title: Our sales workflow
4 | category: Business
5 | weight: -1
6 | ---
7 |
8 | Any sale will go through a portion of the following pipeline;
9 |
10 | 1. **Prospect**; a prospect is a contact that may have a project for us. It may come referred from a friend or someone who came to us.
11 | 1. **Lead**; once we've established that there is indeed a project opportunity, we refer to it as a lead. Most of the time we skip the "prospect" stage since we get contacted directly about our services or a specific project.
12 | 1. **Qualified**; if a need is a fit for us (goal, technology, resources, timeline), we move a lead to "qualified" and finish collecting all the information we need from the client to prepare an estimate.
13 | 1. **Negotiating**; once the client received the estimate, we often negotiate terms (price, scope, timeline).
14 | 1. **Won** or **Lost/Rejected**; either we come to an agreement with the client or we don't. Whether it's because the client refuses our terms ("Lost") or because we decide it isn't a fit ("Rejected").
15 | 1. **Revisit**; prospects or leads are sometimes delayed
16 |
17 | We use mainly two tools through this pipeline;
18 |
19 | - [Streak](https://www.streak.com/) to track connections (people we're introduced to or meet) and potential leads directly in Gmail. It's particularly useful to share email threads without CC'ing a ton of people (and track if people have opened your emails).
20 | - The [GitHub sales repo](https://github.com/Wiredcraft/sales) where we coordinate the work on estimates. An issue is created automatically if the lead is using [our online form](https://wiredcraft.typeform.com/to/GG4GQz). It helps facilitating the work on an estimate with the rest of the team for a qualified lead.
21 |
22 | To summarize:
23 |
24 | 1. Track your connections through the Streak "Connections" pipeline.
25 | 1. Track leads through the Streak "Sales" pipeline.
26 | 1. To get an estimate, coordinate with the team on GitHub.
27 |
28 | Refer to the FAQ about [how to track contacts and opportunities](https://github.com/Wiredcraft/wiredcraft.github.io/wiki/How-to-track-contacts-%26-opportunities%3F) for additional information.
29 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-create-tagged-links-to-track-your-job-ad-performance.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Create tagged links to track your job ad performance
3 | category: Marketing
4 | ---
5 |
6 | The general idea is to tag links which drive people on Wiredcraft.com through job ads.
7 | By doing so, you can get relevant metrics such as unique pageviews, conversion rate, bounce rate.
8 |
9 | Below is the step-by-step procedure to do so:
10 |
11 | 1. Go on the URL builder tool provided by Google: [https://support.google.com/analytics/answer/1033867?hl=en](https://support.google.com/analytics/answer/1033867?hl=en)
12 | 2. Fill the fields as follow:
13 | * **Website URL**: should be the job description on Wiredcraft.com (ex.:https://wiredcraft.com/jobs/mobile-developer/)
14 | * **Campaign Source**: the website where the job has been published (ex.:Lagou, V2EX, LinkedIn)
15 | * **Campaign Medium**: the type of website on which the job has been published (ex.:job platform, social network)
16 | * **Campaign Term**: leave it blank as it's not paid ads
17 | * **Campaign Content**: this field is to evaluate several versions of the same text while being on the same job portal and using the same job ad on Wiredcraft.com (ex:1.0)
18 | * **Campaign Name**: this field is for the job title (ex.: Mobile Developer)
19 | 3. Click on Generate URL and copy it
20 | 4. Go on [https://bitly.com/](https://bitly.com/) and minimize your URL
21 | 5. Replace the original link (https://wiredcraft.com/jobs/mobile-developer/) by the tag rich link (https://wiredcraft.com/jobs/mobile-developer/?utm_source=Lagou&utm_medium=job%20platform&utm_content=1.0&utm_campaign=Mobile%20Developer)
22 |
23 | The following links are already tagged:
24 | * Back End Developer - V2EX: http://bit.ly/296upc2
25 | * Back End Developer - Lagou: http://bit.ly/293Z0JO
26 | * Front End Developer - V2EX: http://bit.ly/29n5uz6
27 | * Front End Developer - Lagou: http://bit.ly/296xcSu
28 | * Front Developer - Jobtong: http://bit.ly/299BoS4
29 | * DevOps Engineer - Lagou: http://bit.ly/293YGLb
30 | * DevOps Engineer - V2EX: http://bit.ly/299zS2m
31 | * DevOps Engineer - Jobtong: http://bit.ly/292WcK7
32 | * Mobile Developer - Lagou: http://bit.ly/291PFwv
33 | * Junior Marketer - Douban: http://bit.ly/29ywxZr
34 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-how-to-get-to-a-signed-contract.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: How to get to a signed contract?
3 | category: Business
4 | ---
5 |
6 | When we win a project (see [our sales workflow](http://playbook.wiredcraft.com/article/our-sales-workflow/)), we usually prepare a contract (although larger clients often have their own SOW or consulting agreement template).
7 |
8 | Preparing a contract is pretty straightforward once you have the estimate done;
9 |
10 | 1. **Gather the legal details from the client** (you can use [the Google Form](https://docs.google.com/forms/d/1sh4hYsdE5zEMvrH_RDab0fKb3iSUyCFmgDQbv7Clz5Q/viewform) for that1). This includes;
11 | - The full legal name of the client's organization,
12 | - The full legal address of the client's organization,
13 | - The name and contact info (phone number & email address) of the client's point of contact,
14 | - The name of the client's signee.
15 | 1. **Copy the [contract template](https://docs.google.com/document/d/1i-f9Fqpjf4evghr2Et9Sj1-sSaCN_M4tYLXsj1NdMkk/edit#)**, or alternatively the template from the client, from Google Docs into the proper folder (`WCL Business › Projects › CLIENT_NAME`). The file should be name something like `Wiredcraft-CLIENT_NAME-PROJECT_NAME`.
16 | 1. **Fill it in** with both the legal details and the content from the estimate (see annotation highlighted in yellow throughout the template).
17 | 1. **Submit the contract to the client**. If possible use [HelloSign](http://hellosign.com) to get it signed (you can also share it as a PDF or a view-only Google Doc otherwise).
18 | 1. **Prepare invoicing**. Once the client has signed the contract, prepare and schedule all the invoices based on the payment schedule (we use [Wave](https://www.waveapps.com/)).
19 |
20 | Note that if the client is asking for any kind of modification of our contract template, this need to be reviewed and analyzed by a more senior team member.
21 |
22 | 1: this form [can be edited there](https://docs.google.com/a/wiredcraft.com/forms/d/1sh4hYsdE5zEMvrH_RDab0fKb3iSUyCFmgDQbv7Clz5Q/edit?usp=forms_home&ths=true) and will record results [a spreadsheet available in `WCL Business › Forms`](https://docs.google.com/spreadsheets/d/15VvzZ8ryJz6frRWc6cQOAjQrlRBxviWPSDpAq8tvHgA/edit#gid=1997577885).
23 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-user-acceptance-test.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: User Acceptance Test (UAT)
3 | category: Projects
4 | ---
5 |
6 | ## Before starting
7 |
8 | It is necessary that the following conditions are met:
9 |
10 |
11 | 1. Outline and validate the **User journeys**
12 | 2. **Platform code** should be fully developed
13 | 3. Ensure the **UAT environment** is ready and stable
14 | 4. Depending on the type of UAT, we would need:
15 | - For Tester - A set of **test cases**, each case covering a specific usage scenario
16 | - For users - **A script** allowing containment of users without steering them too much in the specifics
17 | 5. **Test accounts** for all users involved allowing access to the features behind any authentication
18 | 6. If tests are done in a **control environment** it is necessary to ensure **resources are booked** and they fit the targeted **user profile(s)**
19 |
20 | ## During the session
21 |
22 | It is important to:
23 |
24 |
25 | 1. Ensure the good conduct of **UAT execution** by testing case or script
26 | 2. **Write down all issues** that arise and gather as much information as possible e.g. device type, OS number, screenshots, gif, user feedback, etc.
27 |
28 | ## Following the session
29 |
30 | Ensure that you work with the team to:
31 |
32 | 1. **Import all issues** in the preferred tracking tool (e.g. Github ) ensuring to provide at least the following information:
33 | - Severity - By decreasing severity: Fatal, Critical, Major, Minor or Enhancement
34 | - Description - An exhaustive description of the issue encountered
35 | - Steps To Reproduce - The actual steps to reproduce the issue
36 | - Actual Result - The current result
37 | - Expectation Result - The expected result
38 | - Device - The type of device
39 | - OS Version - The OS version used
40 | 2. The development team will assess, work and deploy a **development fix** for the identified issues
41 | 3. **Verify the fix** is valid and **close the issue**
42 |
43 | ## After the UAT sprint
44 |
45 | Make sure to:
46 |
47 |
48 | 1. **Compile an UAT report** with a summary of all issues encountered, severity breakdown, notes on quality, etc.
49 | 2. Move **feature change issues** or UI/UX changes to future backlog/phases
50 | 3. **Re-assess** the targeted **user profile** if necessary
51 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-ui-ux-design.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: UI & UX design
3 | category: Design
4 | ---
5 |
6 | When designing software, we refer to 2 main activities;
7 |
8 | - **User Experience (UX) is about how things work**. It is usually associated with a collection of user-centric activities; user research, user flows, information architecture, wireframes... Its goal usually is about making things easy and intuitive for the end-user.
9 | - **User Interface (UI) is about how things look**. It can overlap with some of the UX activities (e.g. wireframes), but is often more focused on wireframes, mockups, front-end code... The goal often is to define a consistent and pleasing visual "language" for users.
10 |
11 | These activities usually run alongside through the whole project; UX and UI are rarely "done" (but so is software). They revolve around one of these tools/deliverables;
12 |
13 | - **User flow, Wireframes & Mockups**; user flows and wireframes are probably the most ubiquitous tools for us. We almost exclusively design them with paper. We usually create mockups and final assets with [Sketch](https://sketchapp.com/) and share them as interactive prototypes with [InVision](https://www.invisionapp.com/). We sometimes augment these tools with Adobe Illustrator, Adobe Premiere & Quartz Composer for specific needs (branding and video montage).
14 | - **[User & Stakeholder Interviews](https://hackpad.com/Interviews-Jqm1k2OoJbn)**; we run interviews with users and the project stakeholders to better understand the context of how the software is used, and its purpose. You can refer to the ["Understand" phase of our product design process](https://wiredcraft.com/blog/how-we-design-products/#understand).
15 | - **User data; surveys, analytics, user testing...**; these are typically preformed when the project has already been launched. Analytics tools (such as Google Analytics) are usually a must.
16 | - **User personas**; user personas are a great way to improve the team's understanding of the users they're designing for, and help us empathize with them.
17 | - **A/B tests**; we try and take as much of our design decisions with data. A/B tests are a great way to evaluate which of our variants (*see ["Diverging"](https://wiredcraft.com/blog/how-we-design-products/#diverge) in our product design process*) perform better.
18 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-ensuring-quality.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Ensuring quality
3 | category: Projects
4 | latest_date: 2018-12-01
5 | latest_author: hunvreus
6 | ---
7 |
8 | The goal of QA is to defend the quality of the deliverables (and as the reste of the team to get things done). This is ensured through:
9 |
10 | 1. **Inclusion** of the QA team in all relevant projects meetings (daily scrum).
11 | 2. **Continuous testing** of the functionalities.
12 | 3. **Validation** based on acceptance criteria.
13 |
14 | ### First steps as a QA team
15 |
16 | The QA team should start the sprints with:
17 |
18 | 1. Test cases preparation.
19 | 2. Test case execution.
20 | 3. Test case dodcumentation.
21 |
22 | ### Continuous testings
23 |
24 | Continuous testing is implemented at various stages:
25 |
26 | * **Unit testing**: tests of the smaller component of the system (*e.g.* [QUnit](https://qunitjs.com/)).
27 | * **Integration testing**: exercise an entire subsystem and ensure that a set of components play nicely together (*e.g.* [Travis CI](https://travis-ci.com/)).
28 | * **Acceptance testing**: follow acceptance criteria from user story (*e.g.* [Cucumber](https://cucumber.io/)).
29 | * **Functional testing**: verify end-to-end scenarios that your users will engage in.
30 | * **System Testing / Regression Testing / UAT**:
31 |
32 | Depending on your development workflow or requirements additional tests can be (and should be) implemented, such as regressions testing, system testing, load testing, smoke testing or UATs.
33 |
34 | ### Passing QA
35 |
36 | The QA is considered successful when:
37 |
38 | * Acceptance criteria are met.
39 | * Code is reviewed by another development team member.
40 | * Test cases are written.
41 | * Unit tests and UI automation tasks are written.
42 |
43 | ### Dos and don’ts
44 | **Definitely do**
45 |
46 | * Remove ambiguity from user stories (ensure every user story is testable and includes acceptance criteria).
47 | * Don’t ignore non-functional testing such as performance and security.
48 | * Do both functional and non-functional testing from the very start of the project.
49 | * Manage testers Day-to-Day.
50 | * Identify the tests up-front before the User Story is implemented (if you do not know how to test, how can you).
51 |
52 | **Do not**
53 |
54 | * Exclude of QA team.
55 | * Wait for the sprint to be finalize to start tests.
56 | * Rely on manual testing.
57 | * Trying to be predictive rather than adaptive.
58 |
--------------------------------------------------------------------------------
/_layouts/default.html:
--------------------------------------------------------------------------------
1 | {% assign build_time = site.time | date: "%Y%m%dT%H%M%S" %}
2 | {% include utils/i18n.liquid %}
3 | {% include utils/path.liquid %}
4 |
5 |
6 |
7 |
8 | {% if site.google_tag_manager %}{% include google/tag-manager.html %}{% endif %}
9 |
10 | {% if depth > 0 %}{{ page.title }} | {{ site.title }}{% else %}{{ site.title }} | {{ page.title }}{% endif %}
11 |
12 |
13 |
14 |
15 |
16 |
17 | {% include seo.html %}
18 |
19 |
20 |
21 |
22 |
23 |
24 | {% include favicons.html %}
25 |
26 |
27 |
28 |
29 |
30 |
31 | {% if site.google_tag_manager %}{% include google/tag-manager-noscript.html %}{% endif %}
32 |
33 | {{ content }}
34 |
35 |
38 |
39 |
40 |
41 |
44 |
45 |
46 |
47 |
48 |
49 |
50 |
51 | {% for script in page.scripts %}{% endfor %}
52 |
53 |
54 |
55 |
--------------------------------------------------------------------------------
/_includes/seo.html:
--------------------------------------------------------------------------------
1 | {% assign description = site.description %}
2 | {% if page.description %}{% assign description = page.description | strip_html | escape %}
3 | {% elsif page.excerpt %}{% assign description = page.excerpt | strip_html | escape | strip_newlines %}{% endif %}
4 | {% assign image = site.image | prepend: site.baseurl | prepend: site.url %}
5 | {% if page.image %}{% assign image = page.image | prepend: site.baseurl | prepend: site.url %}{% endif %}
6 | {% assign twitter = site.twitter | prepend: '@' %}
7 | {% if page.twitter %}{% assign twitter = page.twitter %}{% endif %}
8 | {% assign keywords = site.keywords %}
9 | {% if page.tags %}{% assign keywords = keywords | concat: page.tags %}{% endif %}
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
32 |
33 |
34 |
35 | {% if depth == 0 %}
36 |
37 |
60 | {% endif %}
61 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-how-to-track-contacts-and-opportunities.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: How to track contracts & opportunities?
3 | category: Business
4 | ---
5 |
6 | [Streak](http://streak.com) is a Gmail plugins that allows us to:
7 |
8 | 1. **Track** email threads according to a pipeline, making it easier to understand the progress and actions required for ongoing discussions.
9 | 1. **Schedule** emails to be sent at a specific time. If you schedule an email to be sent at 9:00 AM for the recipient, chances are that you'll be at the top of that person's inbox when he/she arrives at the office.
10 | 1. **Check** that a person has read your email. (We get desktop notifications!)
11 | 1. **Share** discussions with each other without having to CC to oblivion.
12 |
13 | We have two main pipelines for the sales channel:
14 |
15 | - The **"Connections" pipeline**, which helps us track ongoing discussions with interesting contacts who may lead to an opportunity (directly or indirectly). These are typically people we've been introduced to, met (at an event for example) or reached out to.
16 | - The **"Sales" pipeline** which tracks all sales opportunities coming connections, direct email inquiries, our website, phone calls...
17 |
18 | ## Connections
19 |
20 | 1. **Contacted**; for contacts you reach out to (e.g. sending an email after meeting at an event),
21 | 1. **Connected**; once the person answered,
22 | 1. **Contact back**; for people you should get back in touch with (e.g. some folks you need to ping next time you're in town).
23 |
24 | There are a few fields for this box that needs to be filled in for segmentation; location (particularly useful when you are in town and want to get back in touch with folks) and company.
25 |
26 | ## Opportunities
27 |
28 | 1. **Prospect**: potential sales are possible but not yet confirmed,
29 | 1. **Lead**; at this stage we've established that there is indeed the need for or possibility to provide our services,
30 | 1. **Qualified**: qualified leads have been vetted as a fit for us - we usually start the estimate process at that stage by creating a [GitHub issue in the sales repo](https://github.com/Wiredcraft/sales/issues) (see [[How to prepare an estimate?]]),
31 | 1. **Negotiating**: once the estimate has been submitted to a client, we sometimes go back and forth about the price, scope, or conditions,
32 | 1. **Won** or **Lost & Rejected**: we either win the project, or we don't (either because we decide against it or because the client picks another vendor),
33 | 1. **Revisit**: usually used when projects are put on pause and we need to recontact the client about it at a later date.
34 |
35 | Make sure that you associate all emails to the proper box and regularly update and review your various opportunities.
36 |
--------------------------------------------------------------------------------
/_sass/partials/_modal.scss:
--------------------------------------------------------------------------------
1 | @if index($partials, modal) {
2 | .modal {
3 | background: rgba($black, 0);
4 | bottom: 0;
5 | left: 0;
6 | opacity: 0;
7 | overflow-y: auto;
8 | position: fixed;
9 | right: 0;
10 | text-align: center;
11 | top: 0;
12 | transition-property: opacity, visibility;
13 | transition-duration: $ease/2;
14 | visibility: hidden;
15 | z-index: 9999;
16 | .box {
17 | background: #FFF;
18 | border: 1px solid $grey-2;
19 | border-radius: 2*$radius;
20 | box-shadow: $shadow-2;
21 | display: block;
22 | left: 50%;
23 | max-width: 24*$space;
24 | opacity: 0;
25 | position: absolute;
26 | text-align: left;
27 | top: 50%;
28 | width: 90%;
29 | transform: translate(-50%, -50%) scale(0.6);
30 | transition-property: opacity, transform;
31 | transition-duration: $ease/2;
32 | width: 90%;
33 | &.larger {
34 | max-width: 36*$space;
35 | }
36 | &.large {
37 | max-width: 48*$space;
38 | }
39 | &.smaller {
40 | max-width: 18*$space;
41 | }
42 | &.small {
43 | max-width: 12*$space;
44 | }
45 | > .header,
46 | > .body,
47 | > .footer {
48 | padding: $space/2 1.5*$space/2;
49 | }
50 | > .header {
51 | border-bottom: 1px solid $line-3;
52 | h2 {
53 | font-size: inherit;
54 | line-height: inherit;
55 | margin: 0 ($space + $space/4); // Accounts for the close icon
56 | padding: 0 $space/4;
57 | text-align: center;
58 | }
59 | .close {
60 | float: right;
61 | svg {
62 | fill: $grey-2;
63 | height: $space;
64 | transition-property: fill;
65 | transition-duration: $ease;
66 | width: $space;
67 | }
68 | &:hover {
69 | svg {
70 | fill: $grey;
71 | }
72 | }
73 | }
74 | }
75 | .body {
76 | max-height: calc(100vh - 108px - 96px);
77 | overflow: auto;
78 | > *:last-child {
79 | margin-bottom: 0;
80 | }
81 | }
82 | .footer {
83 | background: $light;
84 | border-radius: 0 0 $radius $radius;
85 | border-top: 1px solid $line-3;
86 | text-align: right;
87 | }
88 | }
89 | &.active {
90 | background: rgba($black, 0.3);
91 | opacity: 1;
92 | visibility: visible;
93 | .box {
94 | opacity: 1;
95 | transform: translate(-50%, -50%) scale(1);
96 | }
97 | }
98 | }
99 | }
100 |
--------------------------------------------------------------------------------
/_sass/partials/_form.scss:
--------------------------------------------------------------------------------
1 | @if index($partials, form) {
2 | .field {
3 | margin-bottom: 1.5*$space/2;
4 | .description {
5 | color: $grey;
6 | display: block;
7 | margin-top: $space/4;
8 | }
9 | &.full-width {
10 | input,
11 | .select,
12 | .select select,
13 | textarea {
14 | width: 100%;
15 | }
16 | }
17 | }
18 |
19 | fieldset {
20 | border: 1px solid $line;
21 | border-radius: $radius;
22 | margin: 0 0 $space/2;
23 | padding: $space/2 $space/2 0;
24 | position: relative;
25 | }
26 |
27 | label,
28 | .label {
29 | @include font-size($small);
30 | font-weight: 500;
31 | text-transform: uppercase;
32 | display: block;
33 | }
34 |
35 | input,
36 | textarea,
37 | select {
38 | box-shadow: none;
39 | color: inherit;
40 | font-family: inherit;
41 | font-size: inherit;
42 | line-height: inherit;
43 | }
44 |
45 | input,
46 | textarea,
47 | .select select {
48 | background: $background;
49 | border: 1px solid $line;
50 | border-radius: $radius;
51 | box-sizing: border-box;
52 | display: inline-block;
53 | padding: $space/4 $space/2;
54 | transition-property: border;
55 | transition-duration: $ease;
56 | &.small {
57 | padding: $space/8 $space/4;
58 | }
59 | &:hover {
60 | border-color: shade($line, 20%);
61 | }
62 | &:active,
63 | &:focus {
64 | border-color: $blue;
65 | box-shadow: 0 0 0 2px rgba($blue, 0.2);
66 | outline: none;
67 | }
68 | &[disabled],
69 | &[disabled=disabled],
70 | &[disabled=true],
71 | &[disabled],
72 | &[readonly=true],
73 | &[readonly=readonly],
74 | &[readonly] {
75 | background: $light;
76 | border-color: $line-2;
77 | color: $grey;
78 | &:active,
79 | &:focus,
80 | &:hover {
81 | border-color: $line-2;
82 | box-shadow: none;
83 | cursor: not-allowed;
84 | }
85 | }
86 | }
87 |
88 | .select {
89 | cursor: pointer;
90 | display: inline-block;
91 | position: relative;
92 | & > select {
93 | appearance: none;
94 | -webkit-appearance: none;
95 | cursor: pointer;
96 | padding-right: 1.5*$space;
97 | }
98 | &:after {
99 | bottom: 0;
100 | content: '▾';
101 | cursor: pointer;
102 | @include font-size($smaller);
103 | line-height: 120%;
104 | pointer-events: none;
105 | position: absolute;
106 | right: $space/2;
107 | top: 50%;
108 | transform: translateY(-50%);
109 | }
110 | }
111 |
112 | .actions {
113 | margin-top: $space;
114 | > * {
115 | margin-right: $space/4;
116 | }
117 | }
118 | }
119 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-culture.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Culture
3 | category: Company
4 | sticky: true
5 | ---
6 |
7 | As our team came together, some recurrent behaviors, values and interests started to emerge. What was originally the shared direction and set of personal values of our members cemented into a very tangible company culture. While it may sound enterprise-speak, it is important as we grow that we better identify our culture and work hard on preserving it.
8 |
9 | ## Vision & Mission
10 |
11 | We envision **a team of experts working on projects that have an impact**. To make this a reality, both for our team and the teams we partner with, we believe in fostering a transparent, unassuming and meritocratic environment where people can freely experiment and organize to reach the best of our abilities.
12 |
13 | We sometimes refer to our unofficial motto: "Build sh*t that matters".
14 |
15 | ## Values
16 |
17 | Our vision and mission articulate around a few key values:
18 |
19 | - **Care**. We're passionate about our craft and what we work on. The projects we engage in tend to have a high impact, either in scale (e.g. building apps for millions of users with Starbucks) or purpose (e.g. designing the software running the Myanmar elections). We "build sh*t that matters."
20 | - **Do**. We prefer experimenting early and iterating upon our failures (and sometimes successes). This approach is far more efficient and fast than careful planning. When in doubt, frame the assumption you want to validate and design a way of validating it by doing. If somebody or something is a bottleneck, it is often better to not wait and go for it.
21 | - **Share**. Our assumption is that most things should be shared publicly, and virtually anything should be accessible to our team members. We overuse tools like GitHub, Google Docs or Slack because it makes it easy to share everything we produce, including our discussions, with our team and the teams we work with.
22 | - **Play nice**. Assume that the people you work with are well intentioned and capable. This is a prerequisite for people feeling comfortable experimenting, sharing and, more generally, collaborating. Just don't be a jerk.
23 | - **Be skeptical**. You should assume that most things we do or use could be improved, changed or dropped. It's safe to assume that the tools and processes are the results of informed decisions, but not always. And even when they are, they can be challenged. Things often work until they don't: teams grow, technologies evolve, behaviors adapt.
24 | - **[Loosely coupled, tightly aligned](/Company/loosely-coupled-tightly-aligned.html)**. This concept somehow permeates all layers of our organization. Our software is built upon this principle (e.g. micro-services, single page apps), and so are our teams, methodologies, and tools. Spotify's [engineering](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) [culture](https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/) is a great illustration of that concept.
25 |
--------------------------------------------------------------------------------
/assets/search.js:
--------------------------------------------------------------------------------
1 | /**
2 | * Search
3 | */
4 |
5 | // Constructor
6 | var Search = function(params) {
7 | this.el = params.el;
8 | if (params.resultsEl) {
9 | this.resultsEl = params.resultsEl;
10 | }
11 | else {
12 | this.resultsEl = document.createElement('div');
13 | this.resultsEl.classList.add('search-results');
14 | this.resultsEl.innerHTML = '
Type in keywords
';
15 | this.el.after(this.resultsEl);
16 | }
17 | this.url = params.url;
18 | this.idx = null;
19 | this.content = [];
20 | this.items = [];
21 | this.results = [];
22 | this.init();
23 | }
24 |
25 | // Fetch the content, build the search index and listen to input changes
26 | Search.prototype.init = function() {
27 | var that = this;
28 | var request = new XMLHttpRequest();
29 | request.open('GET', this.url, true);
30 | request.onload = function() {
31 | if (request.status >= 200 && request.status < 400) {
32 | that.content = JSON.parse(request.responseText); // Content retrieved
33 | that.index(); // Build the index
34 |
35 | // We attach search to the changes of input
36 | that.el.addEventListener('keyup', function () {
37 | if (this.value) {
38 | that.search(this.value);
39 | that.display();
40 | }
41 | else {
42 | this.resultsEl.innerHTML = '
';
91 | }
92 | }
93 |
94 | // Run the search with Lunr.js
95 | Search.prototype.search = function(keywords) {
96 | this.results = this.idx.search(keywords);
97 | }
98 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-recruiting.md:
--------------------------------------------------------------------------------
1 | ---
2 | sticky: true
3 | title: Recruiting
4 | category: Employees
5 | ---
6 |
7 | - **Job ads**: open positions are all [advertised on the website](https://wiredcraft.com/about/#jobs). If your team needs to recruit a profile that is not advertised there, talk to your team and [add a new job ad on the website](https://github.com/Wiredcraft/marketing/tree/master/_jobs). Make sure you understand [how to write a job ad](/article/where-to-post-job-ads) beforehand.
8 | - **Recruitment priorities**: we usually set recruitment priorities based on capacity planning. Let your team leader know if you think a certain profile should be a priority.
9 | - **Advertisement**: job ads (especially prioritised ones) are posted on multiple channels; social media (LinkedIn, Facebook, WeChat), newsletter, job platforms (e.g. Lagou), communities (e.g. V2EX, Hacker News)... You can read more about **[where we post which job ads and why](/article/where-to-post-job-ads)**.
10 | - **Applications**: we receive applications through multiple channels:
11 | - **Form on the site** (e.g. [apply to the front-end developer position](https://wiredcraft.com/jobs/front-end-developer/#application)) or **email to job@wiredcraft.com or jobs@wiredcraft.com**. This automatically creates an issue in [the recruitment repo](https://github.com/Wiredcraft/recruitment) and sends an email to the candidate.
12 | - **From 3rd parties** (e.g. Lagou). For these, the perations team takes care of manually creating issues on GitHub.
13 | - **Personal networks**. Members of the team often either refer or get contacted by potential recruits. Manually add an entry in [the recruitment repo](https://github.com/Wiredcraft/recruitment) when this happens.
14 | - **Applications review**: as previously mentioned, all applications are tracked in [`Wiredcraft/recruitment`, the recruitment repo](https://github.com/Wiredcraft/recruitment). This provides the opportunity for anybody on the team to evaluate and comment on applications.
15 | - **Screening calls & Interviews**: for interesting candidates, we often recommend to do a first 15 minutes screening call to assess if it's worth moving to a face to face interview. Feel free to skip this step if you feel the candidate is interesting enough.
16 | - **Interviews**: we try and do face to face interviews whenever possible, and video otherwise. These are usually run by the team leader. They're usually divided in 3 parts (read [the how-to if you need to interview a candidate](/article/how-to-interview-a-candidate)):
17 | - **First a 20 minutes discussion** to evaluate the candidate's experience, skills and fit (~20 minutes)
18 | - **Then a 10 minutes Q&A** for the candidate to ask questions about the position, company...
19 | - **Finally, we give the candidate a test**. If possible, this is done on-site (~60 minutes), otherwise sent online.
20 | - **Offers**: based on the results of the interview and test, we may decide to make an offer. We use a standard salary table to begin salary negotiations. Offers are validated by operations and the team leader before they're sent out.
21 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-a-few-more-things.md:
--------------------------------------------------------------------------------
1 | ---
2 | sticky: true
3 | title: A few more things
4 | category: Business
5 | ---
6 |
7 | - **We do not do** military (e.g. surveillance software or weaponry related software/hardware), porn, politics and religion.
8 | - **Trust your gut**. If you feel squeamish about a client or a deal, chances are there's a reason. At the very least share your concerns with your colleagues. If they feel the same, consider dropping it.
9 | - **Take the high road**. Some people will behave poorly, especially when money is involved. Deals will fall through, people will try and use you, competitors will play dirty. Be graceful in these situations, people will remember you for it and karma will take care of things1.
10 | - **Know your value**. Clients will try and get the best deal they can, but if you sell yourself cheap you'll end up hurting both parties; the lesser the client values your time, the harder the relationship. And less resources means less opportunities for us to do a great job.
11 | - **Don't give guesstimates or price ranges**. [Anchoring](https://en.wikipedia.org/wiki/Anchoring) means that people will judge all subsequent prices you give them based on that initial (inaccurate) price you gave them. Similarly, never give a range, people will expect the lower end of the range2.
12 | - **Focus on quality, rather than quantity**. The shotgun approach isn't an efficient way of going at sales. Good business people usually bring the majority of the revenue with significantly fewer, high return clients. This is why we cold email only in very specific cases (see *[[How to generate leads?]]*).
13 | - **Be relentless**. Once you're exploring a lead, your goal is to close, either with a "yes" or a "no". Be patient and keep on following up with people until you get a final answer.
14 | - **Connectors vs. Prospects**: many leads come from people who are well connected and eager to introduce us or pitch our team others. Value your relationship to these people, they often act like ambassadors or sales people for us.
15 | - **Build rapport**; make sure you always personalize your relationships. If you cold contact somebody, make sure you establish how you're related to him (e.g. common interest in a technology). Make sure you take note of personal details people share with you. People do business with people, and they're much more likely to do so if they like you.
16 | - **Be concise**; especially when sending emails, you want to avoid wasting people's time. Build a rapport (e.g. something about them that led you to contact them), explain who you are and tell them why you're contacting them. Nobody wants to read a boilerplate pitch from a stranger.
17 | - **Be resourceful**; finding a way to get in touch and establishing a rapport with somebody is pretty easy nowadays. People are sharing information about themselves all over LinkedIn, Twitter, GitHub, Facebook... Social hack your way to an introduction or a coffee.
18 | - **Be confident**; most people have no idea what they're doing.
19 |
20 | 1: “If you wait by the river long enough, the bodies of your enemies will float by.”
21 | 2: this is also why you never should give a salary range when negotiating your compensation for a job.
22 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-technologies-tools.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Technologies & tools
3 | category: Development
4 | sticky: true
5 | weight: -10
6 | ---
7 |
8 | **As with most things at Wiredcraft, you are strongly encouraged to challenge our way of doing things**. Developers regularly introduce new languages, frameworks or platforms. If you feel strongly about a technology or a tool, speak up. You only need to convince people on your team of its benefits and maintainability.
9 |
10 | With that being said, we often make the following choices based on past experience;
11 |
12 | ## Technologies
13 |
14 | - **We usually build micro-services and APIs with [Node.js](https://nodejs.org/en/)**, often with the [Loopback](http://loopback.io) framework. We're also increasingly relying on [Golang](https://golang.org/).
15 | - **We build Web front-ends with [React](https://facebook.github.io/react/)**, usually using [Redux](http://redux.js.org/). We've also used [AngularJS](https://angularjs.org/).
16 | - **For data or DevOps related work (scrapper, data science, ...) we usually pick [Python](https://www.python.org/)**, with [Flask](http://flask.pocoo.org/) if we need a lightweight API or [Django](https://www.djangoproject.com/) when we need CRUD or ACL.
17 | - **For native mobile apps, we prefer [Kotlin](https://kotlinlang.org) and [Swift](https://developer.apple.com/swift/)**. We've experimented with [React Native](https://facebook.github.io/react-native/) as well.
18 | - **For data visualizations, [D3.js](https://d3js.org/) & [Mapbox.js](https://www.mapbox.com/mapbox.js/api/v2.4.0/) are usually enough** but we sometimes use additional libraries like [Chartist.js](https://gionkunz.github.io/chartist-js/)
19 | - **For data storage, we usually go with [CouchDB](http://couchdb.apache.org), [CouchBase](http://couchbase.com), [PostgreSQL](https://www.postgresql.org/), [Elasticsearch](https://www.elastic.co/products/elasticsearch) or [Redis](http://redis.io)** depending on the use case. Usually CouchDB for NoSQL, or CouchBase if we need to scale, PostgreSQL for relational data, Elasticsearch for full-text search and reporting, and Redis for caching or simple key/value storage (e.g. sessions).
20 | - **We benchmark performances with [Locust](http://locust.io/) or [ApacheBench](https://httpd.apache.org/docs/2.4/programs/ab.html)**.
21 | - **For asynchronous messaging, we usually go for [RabbitMQ](https://rabbitmq.com) or [NSQ](http://nsq.io)**.
22 |
23 |
24 | ## Tools & Services
25 |
26 | *To access and/or manage some of these tools, you'll need to be invited to our [LastPass](http://lastpass.com) company account.*
27 |
28 | - **[GitHub](http://github.com/Wiredcraft)**; all code and tasks live there ([we actually use GitHub for pretty much anything from DevOps to recruitment](https://wiredcraft.com/blog/github-for-everything/)).
29 | - **[TravisCI](https://travis-ci.com/) & [Coveralls](https://coveralls.io/)**; to run our tests and check on test coverage.
30 | - **[HockeyApp](https://www.hockeyapp.net/features/)**; to deliver mobile apps for testing.
31 | - **[Fabric](https://get.fabric.io)/[Crashlytics](http://try.crashlytics.com/) & [Google Analytics](https://analytics.google.com/)**; for crash and usage tracking (mostly for mobile apps).
32 | - **[Docker Hub](https://hub.docker.com/)**; for hosting our Docker images.
33 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-case studies guidelines.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Case studies guidelines
3 | category: Marketing
4 | ---
5 |
6 | ## Context
7 |
8 | **What**; an article that illustrates how we solve a business problem for one of our clients.
9 |
10 | **Why**; creating interest from potential customers and recruits (and maybe audience).
11 |
12 | **How**;
13 | - Demonstrating our understanding of the business problem
14 | - Demonstrating our capabilities (strategy, tech, design, marketing…)
15 | - Demonstrating our expertise (New Retail, WeChat, FMCG…)
16 |
17 | **Where**; our case studies are blog posts with a pre-defined format (see below) and a special tag. This allows us to push our case studies on the blog and prevents us from being stuck with a rigid format (which may not fit all projects). We still display case studies separately in some places (e.g. home page or work section).
18 |
19 | ## Format
20 | Our format follows the storytelling arc;
21 |
22 | - **Context**; we set the context for the business problem, explaining who the client is.
23 | - **Problem**; what pain point they hit and why. What the challenges are…
24 | - **Development**(action to resolution); where we describe how we went on to solve the problem and what the solution is. Potentially, starting by the solution, and then diving into the specifics (design, tech used…). These specifics are secondary. The main focus should be on business goals/solutions/challenges/
25 | - **Return to normalcy**; explaining how the new situation is opening up new horizons, what the next steps are or providing some amount of perspective (link to other projects or larger discussion).
26 |
27 | ## Dependencies
28 | - **Photos**; better to be taken through the project, but worst case scenario can be reconstructed. They can be taken with a phone as they won’t be displayed in HD in most cases.
29 | - **Assets**; screenshots of the final product, final pro pictures of the product in use, videos…
30 | - **Key numbers**; a series of impressive/relevant metrics or facts (e.g. 100k users within 2 days or 5 weeks to pilot).
31 | - **Technologies**; list of tech we used
32 | - **Testimonial**; from a client. Be sure to write it for them and submit for their edits/approval.
33 | - **Notes**; from the leaders of the project. This needs to be done through questions face to face with these individuals. Questions to ask:
34 | - Learnings
35 | - What was hard, what was easy
36 | - What was good or bad
37 | - What would you change if you could
38 | - What was the overall methodology
39 | - What tools did you use
40 | - …
41 |
42 | ## How to get it done?
43 | - A good first milestone is to write the summarized case study. Moreover, if this is ready, we can integrate it in the sales deck.
44 | - Identify who are the leaders on the project.
45 | - Write the context (potentially talk to BD/sales to make sure it’s ok).
46 | - Gather assets (from the design team mostly).
47 | - Once you understand roughly the final product, sit down for 5 to 10 minutes with the project leaders (individually) and run them through question to fill in your arc (the development part).
48 | - Once you have a draft, bring in senior staff to help you finalize the first version and provide the last part (esp. perspective bits).
49 |
50 | Don’t overdo it, our case studies can be VERY simple.
51 |
52 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-how-to-organize-a-meetup.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: How to organize a meetup?
3 | category: Marketing
4 | ---
5 |
6 | Events are key for branding and recruitment, as we are able to introduce our company and our brand to the local community. The key to a good event is professional correspondence, consistency, and keeping it fun. We aim to keep our events welcoming to all levels of experience with Tech, not-self promoting, and high quality. The following shows a timeline for hosting an event and the basic processes you should be following.
7 |
8 | ## Meetup Timeline
9 |
10 | - 6-8 weeks before: Create your [goals and think about your ROI](https://docs.google.com/a/wiredcraft.com/document/d/155b4pW-H_5t7lrNFD9h9mCCq79Wo-BRApOaLUGI1yH0/edit?usp=sharing), create your meetup page, and start contacting speakers.
11 | - 4 weeks before have your speakers and venue confirmed
12 | - 4 weeks before schedule, but don’t announce
13 | - 2 weeks before announce on meetup and SNS
14 | - 1 week before blog post and SNS promotion, email
15 | - 2 days/day before reminder- continue promotion
16 | - day of reminder & promotion
17 | - day after post photographs and videos on meetup and upload to google drive, thank you to attendees, speakers and venue sent, follow up with your KPIs and Metrics, create meetup event page for your next event, and follow up on Social Media with your videos and photos
18 |
19 | ## Organizing a meetup event
20 |
21 | 1. **Research by attending other meetup events.** See what you like/dislike about what the other groups are doing and take notes. Find what space in your community is lacking and make that your niche. Important for DC, Berlin and NYC where the communities are very active and there are a lot of nice meetups.
22 | 2. **Create goals for your meetup and KPIs.** What’s the purpose of your meetup? What’s Wiredcraft’s ROI? (Brand awareness, recruitment, newsletter or SNS subscribers?) What size do you want the meetup to be.
23 | 3. **Know who the influencers/speakers are in your community** and reach out to them to speak/suggestions for speakers. Create a [backlog spreadsheet](https://docs.google.com/spreadsheets/d/1ToSKa_N3IAF4lpEOHP8gCsNGtTjlMiLD6Kp_bgXXMt4/edit#gid=1587452805) so you have all necessary information at your fingertips.
24 | 4. **Find Sponsors/Venues.** Make a list and email them so you can plan your meetups well in advance. Ideally you can plan your first two meetups before you even host the first one.
25 | 5. **Meet with the venue.** Important questions - what is there sound system/projector set up (will the speaker need a remote to reach their computer), expected capacity, how many chairs can they provide, area for drinks/food, is it ok to have beer at their venue, who will be responsible for the setup and takedown, are they willing to help sponsor food or anything else? Get their social media and logo for cross promotion. Get their contact number if people can't find the venue.
26 | 6. **Create your budget**
27 | 7. **Create your meetup on meetup.com.** Make sure the purpose and schedule of your meetup is clear in your objective. Allow some time to gain members, about a month. You can schedule the meetup, but it’s not necessary to announce it yet.
28 | 8. **Promote your event.** Reach out to other partner groups to ask them to promote and support on Social media or at their events.
29 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-internal-marketing-strategy.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Internal marketing strategy
3 | category: Marketing
4 | ---
5 |
6 | Our marketing strategy is overall simple and aligned with [our business approach](/article/sales-101/): being **genuine, helpful and trustworthy**.
7 |
8 | We're are a digital product agency. We create digital solutions for the largest brands in the world (with a special focus on luxury, retail and FMCG).
9 |
10 | That includes things like customer loyalty platforms (WeChat, mobile, web), new retail solutions (O2O installations), AI for customer insights...
11 |
12 | ## Tone
13 |
14 | Whether we talk at an event, speak to a client or write a post, our tone is consistent:
15 |
16 | - **Confident & Knowledgeable**; we know what we're talking about and are confident in our opinions and expertise.
17 | - **Upfront & Transparent**; we say it how it is and share as much as we can with the rest of the world1.
18 | - **Witty & Approachable**; we're sometimes cheeky and make sure people know they can reach out.
19 |
20 | 1: This means we sometimes share things that would make others uncomfortable, like sharing our entire way of running our company through this playbook.
21 |
22 | ## Keywords/Topics
23 |
24 | - **Primary**: Agency, Solutions, Product, Digital, Design, Innovation, Enterprise, Loyalty, Retail, FMCG, Luxury, WeChat.
25 | - **Secondary**: DevOps, Javascript, React, Big data, Data science, Machine learning, AI, mini-program, New retail, O2O, Omnichannel, Analytics, Data warehouse.
26 |
27 | ## Mediums
28 |
29 | - **Content**; the most important element of our marketing plan; blog posts and videos (from events). We occasionally get others to write about us (e.g. [TIA Article](http://www.topinteractiveagencies.com/digital/agency/profiles/leadership-style-extreme-minimalism/)).
30 | - **Events**; monthly meetups (e.g. [Shanghai UI/UX](http://www.meetup.com/Shanghai-UI-UX-Designers-Meetup/)) and yearly conferences (e.g. [JSConf China](http://jsconf.cn)). We also participate to and speak at other events (e.g. Barcamp).
31 | - **Newsletters**; we collect email addresses through our blog, events and business development. We reach out to these mailing lists regularly (at least once a month).
32 | - **Social media**; we broadcast our content and events on various social media, with a special focus on WeChat, LinkedIn and Facebook.
33 |
34 | ## Schedule
35 |
36 | **[We track all of the content and events (whether ours or others') in a spreadsheet](https://docs.google.com/spreadsheets/d/1PDNj1Q1pRSjqEYc_-PMEQQWM5gMgB4rDrDRXZEIokLg/edit#gid=1770647921)**.
37 |
38 | The schdule goes roughly as follows;
39 |
40 | - **At least 1 blog post per week**; this excludes "fluff posts" (e.g. new team member joining or upcoming event).
41 | - **2 to 4 meetups per month**; UI/UX (every month in both Berlin and Shanghai), Hacker News (every month in Shanghai), JS meetup (once every two months in Shanghai) and occasionally a few others (DevOps, Ansible, Docker...).
42 | - **2 to 3 newsletters a month**; a personal email from our CEO every couple weeks (includes some insights about a single topic and usually a link to one of our posts) and a summary of the past month (collection of posts from us and others).
43 | - **A WeChat post every week**; which usually points to our latest blog post/case study/event.
44 | - **Posting new content on LinkedIn and Facebook regularly**, either new posts/events/case studies or older popular entries. We cross-post our blog posts on LinkedIn.
45 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-how-to-write-a-case-study.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: How to write a case study?
3 | category: Marketing
4 | ---
5 |
6 | Case studies primarily help us expose our expertise (skills, methodologies, domain knowledge...) and portfolio of clients.
7 |
8 | **Their main audience are potential clients**. Secondarily, it can give job applicants an idea of the type of work we do.
9 |
10 | We prefer short case studies focused on telling a story (like those of [MadeByMany](https://madebymany.com/case-studies/a-world-class-museum-embraces-digital-and-wins), [IDEO](https://www.ideo.com/case-study/cultivating-creative-competitiveness-for-europes-biggest-fashion-platform) or [Pivotal](https://pivotal.io/imapivot/citi)). These stories focus on the strategic achievements rather than just technical details.
11 |
12 | ## Preparatory work
13 |
14 | Before getting started on writing the actual case study, we spend time collecting the raw material;
15 |
16 | 1. **Interview project members**; identify who are the key contributors on our team for this project (lead designer, lead developer, project manager...) and interview them. The hard part here is to avoid getting a simple description of the work done. You want to to hear about the interesting bits;
17 | - What was in place when you joined the project? Was there clear guidelines?
18 | - What was the goal? For the client/our team/yourself?
19 | - What was the challenge? Why? Was there a challenging but interesting part?
20 | - What was your strategy/approach to get this done?
21 | - Did you learn anything new? Especially the non-tech part?
22 | - What resources would best illustrate the work you did (e.g. a screenshots of a dashboard, a picture of a design workshop...)?
23 | - Are you happy about the final product? Why?
24 | - What tools/methodologies/technologies did we use? Anything special about it?
25 | - One thing would you change if you had a chance to start over?
26 | - What would be the next steps?
27 | 2. **[Define the 5 W's](https://en.wikipedia.org/wiki/Five_Ws)**; Who, What, Why, Where & When. These are crucial to help you define [the story arc](https://en.wikipedia.org/wiki/Story_arc) later on.
28 | 3. **Assets collection**; gather everything you can: Wireframes, mockups, screenshots of the final product, photos of the team working... Try and storyboard the photos before you take them, and don't hesitate recreating a scene when needed. Make sure as well that you always have at least one picture of the final product in context (e.g. actual users using an app in a store) and remember to take pictures through the project (especially some that includes the client's teams).
29 | 4. **Metrics**; it is crucial to include a few (usually 3) metrics that help communicate very quickly the project's achievements. For example:
30 | - 100k users within in 2 days
31 | - 10% daily user growth
32 | - 2x revenue on launch day
33 |
34 | ## Writing the case study
35 |
36 | You now have the raw material. You can proceed in three steps;
37 |
38 | 1. **Skeleton**; do not skip this step. You can start by writing the title, then an excerpt and then move on to drafting your [story arc](https://www.thoughtco.com/what-is-narrative-arc-in-literature-852484). It should properly set up the context, challenge and main activities ("highlights") that led us to a solution.
39 | 2. **Draft**; once your skeleton is in place, add flesh to it by writing actual paragraphs. Don't worry about grammar or length, you'll fix that later on. For now, focus on getting some actual content out there.
40 | 3. **Final copy**; gradually trim down and improve the draft to a satisfactory point.
41 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-devops.md:
--------------------------------------------------------------------------------
1 | ---
2 | sticky: true
3 | title: About DevOps
4 | category: Development
5 | ---
6 |
7 | **[DevOps](https://en.wikipedia.org/wiki/DevOps) is nothing more than [agile principles](https://en.wikipedia.org/wiki/Agile_software_development) applied to the interface between software and infrastructure**.
8 |
9 | The goal is to accelerate development, improve quality and lessen the stress on the team. We apply a wide range of methodologies and tools, most of them revolving around the following values;
10 |
11 | - **Open**; Ops and Dev people work as a team from the beginning of the project. Information is transparently shared across the team (e.g. Slack notifications on commits and code deployment), incidents are openly addressed as a team ([5 Whys](https://en.wikipedia.org/wiki/5_Whys) & [After Action Rerport](https://en.wikipedia.org/wiki/After_action_report)).
12 | - **Iterative**; we release and deliver in small increments of changes as quickly as possible. This heavily relies on automation (e.g. Ansible) and continuous everything (e.g. TravisCI, Pipelines).
13 |
14 | ## Best-practices & Toolbox
15 |
16 | - **Monitoring, Logging & Reporting**; we monitor, log and report everything we can with [TIGK](https://www.influxdata.com/products/) (Telegraf, InfluxDB, Grafana & Kapacitor) and [ELK](https://www.elastic.co/products) (ElasticSearch, Logstash & Kibana). We also log errors happening in the clients (React, iOS, Android...) with [Sentry](http://sentry.io) or [Fabric](https://get.fabric.io/).
17 | - **Configuration management & Infrastructure as code**; we scripts everything we can, from deployment pipelines to infrastructure configuration with Python and [Ansible](http://ansible.com).
18 | - **Micro-services and Containers**; [we tend to prefer building SOA](playbook.wiredcraft.com/article/loosely-coupled-tightly-aligned/)1 with lots of small (often state-less) micro-services. We increasingly rely on [Docker](http://docker.com) to deliver these services.
19 | - **[Test-Driven Development](https://en.wikipedia.org/wiki/Test-driven_development) & Continuous testing**; we try and test most things (including things like Ansible playbooks) and continuously run/report these tests in Slack with tools like TravisCI.
20 | - **Testing, Performance & Scalability**; we continuously monitor code benchmarks (e.g. memory usage), run and report tests (even for Ansible) and stress-test services before releasing (using [Locust](http://locust.io/), [ApacheBench](https://httpd.apache.org/docs/2.4/programs/ab.html) or [Siege](https://github.com/JoeDog/siege)).
21 | - **ChatOps**; we over-communicate all development related events in Slack (from commits on GitHub to monitoring failures and deployment status). When possible, we allow users to run commands from Slack using a bot (aka [ChatOps](https://speakerdeck.com/jnewland/chatops-at-github)).
22 | - **[Just-in-time engineering](https://en.wikipedia.org/wiki/Just-in-time_manufacturing)**; we avoid premature optimization (e.g. caching) or over-engineering.
23 | - **5 Whys & AAR**; following an incident, the team gets together and investigate the root cause of the issue using the [5 Whys](https://en.wikipedia.org/wiki/5_Whys) technique. We often send a [AAR](https://en.wikipedia.org/wiki/After_action_report) to stakeholders and/or clients afterwards. We're not looking for a culprit, we're using this as an opportunity to learn and grow.
24 |
25 | 1: Spotify's [engineering](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) [culture](https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/) is a great illustration of that concept.
26 |
--------------------------------------------------------------------------------
/_sass/partials/_button.scss:
--------------------------------------------------------------------------------
1 | @if index($partials, button) {
2 | .button {
3 | background: $background;
4 | border: 1px solid $line;
5 | border-radius: $radius;
6 | box-sizing: border-box;
7 | color: $black;
8 | cursor: pointer;
9 | display: inline-block;
10 | font-weight: 500;
11 | line-height: inherit;
12 | outline: none;
13 | padding: $space/4 1.5*$space/2;
14 | text-align: center;
15 | transition-property: background, border, box-shadow, color;
16 | transition-duration: $ease;
17 | &.smaller {
18 | @include font-size($smaller);
19 | padding: $space/6 1.5*$space/3;
20 | }
21 | &.larger {
22 | padding: $space/3 $space;
23 | @include font-size($smaller);
24 | }
25 | &.processing {
26 | padding-right: 1.5*$space/2 + 1.5*$space/2;
27 | position: relative;
28 | &:before {
29 | @include spinner($space/24, $space/2, #FFF, rgba(#000, 0.1));
30 | content: '';
31 | display: block;
32 | height: 1.5*$space/2;
33 | margin-top: -1.5*$space/4;
34 | position: absolute;
35 | right: 1.5*$space/4;
36 | top: 50%;
37 | width: 1.5*$space/2;
38 | }
39 | &.larger {
40 | padding-right: $space + $space;
41 | &:before {
42 | height: $space;
43 | margin-top: -$space/2;
44 | right: $space/2;
45 | width: $space;
46 | }
47 | }
48 | &.smaller {
49 | padding-right: $space/2 + $space/2;
50 | &:before {
51 | height: $space/2;
52 | margin-top: -$space/4;
53 | right: $space/4;
54 | width: $space/2;
55 | }
56 | }
57 | }
58 | &:hover {
59 | border-color: $primary;
60 | color: $primary;
61 | text-decoration: none;
62 | }
63 | &:active,
64 | &:focus {
65 | box-shadow: 0 0 0 2px rgba($blue, 0.2);
66 | }
67 | &[disabled=disabled],
68 | &[disabled=true],
69 | &[disabled],
70 | &.disabled {
71 | border-color: $line-2;
72 | color: $line;
73 | }
74 | &.primary {
75 | background: $primary;
76 | border-color: $primary;
77 | color: #FFF;
78 | &:hover {
79 | background: darken($primary, 5%);
80 | border-color: darken($primary, 5%);
81 | }
82 | &[disabled=disabled],
83 | &[disabled=true],
84 | &[disabled],
85 | &.disabled {
86 | background: $line;
87 | border-color: $line;
88 | }
89 | }
90 | &.danger {
91 | background: $red;
92 | border-color: $red;
93 | color: #FFF;
94 | &:hover {
95 | background: darken($red, 5%);
96 | border-color: darken($red, 5%);
97 | }
98 | &[disabled=disabled],
99 | &[disabled=true],
100 | &[disabled],
101 | &.disabled {
102 | background: $line;
103 | border-color: $line;
104 | }
105 | }
106 | }
107 |
108 | .bundle {
109 | display: inline-block;
110 | > .button,
111 | > * .button {
112 | border-radius: 0;
113 | border-right-width: 0;
114 | &:hover {
115 | & + .button,
116 | & + * .button {
117 | border-left-color: $primary;
118 | }
119 | }
120 | }
121 | > .button:first-child,
122 | > *:first-child .button {
123 | border-radius: $radius 0 0 $radius;
124 | }
125 | > .button:last-child,
126 | > *:last-child .button {
127 | border-radius: 0 $radius $radius 0;
128 | border-right-width: 1px;
129 | }
130 | }
131 | }
132 |
--------------------------------------------------------------------------------
/_config.yml:
--------------------------------------------------------------------------------
1 | # Site settings
2 | title: The Wiredcraft Playbook
3 | email: hello@wiredcraft.com
4 | description: "How we do things at Wiredcraft, from running our team to building software."
5 | keywords:
6 | - Wiredcraft
7 | - playbook
8 | - best-practices
9 |
10 | # URL
11 | url: "https://wiredcraft.github.io/knowledge"
12 | baseurl: ""
13 |
14 | # Google tracking (Analytics and Google Tag Manager)
15 | # google_tag_manager: GTM-XXXXXX
16 | # google_analytics: UA-XXXXXXX-X
17 |
18 | # SEO
19 | twitter: wiredcraft
20 | facebook: https://www.facebook.com/teamwiredcraft
21 | logo: /assets/logo.png
22 | image: /assets/logo.png
23 | social:
24 | - https://www.facebook.com/teamwiredcraft
25 | - https://twitter.com/wiredcraft
26 | - https://www.linkedin.com/company/wiredcraft
27 | - https://github.com/wiredcraft
28 | - https://weibo.com/1970385015/
29 |
30 | # Sitemap (see sitemap.xml)
31 | sitemap:
32 | changefreq: weekly
33 |
34 | # Build settings
35 | exclude: ['README.md', 'Makefile']
36 |
37 | # Collections
38 | permalink: /:categories/:title/
39 | collections:
40 | posts:
41 | permalink: /:categories/:title/
42 | pages:
43 | permalink: /:categories/:title/
44 | defaults:
45 | - scope:
46 | path: ""
47 | type: pages
48 | values:
49 | layout: topic
50 | class: page
51 | - scope:
52 | path: ""
53 | type: posts
54 | values:
55 | layout: page
56 | class: article
57 | - scope:
58 | path: ""
59 | type: drafts
60 | values:
61 | layout: page
62 | class: article
63 |
64 | # Plugins
65 | plugins: []
66 |
67 | # Multiligual
68 | lang:
69 | - en
70 |
71 | # Jekyll+
72 | jekyllplus:
73 | # Not useful if you're running on GitHub pages
74 | # repo: Wiredcraft/jekyll-basics/master
75 | folders:
76 | file: files
77 | image: images
78 | collections:
79 | pages:
80 | name: Pages
81 | fields:
82 | - name: published
83 | label: Published
84 | type: switch
85 | default: true
86 | - name: title
87 | label: Title
88 | type: string
89 | - name: description
90 | label: Description
91 | type: string
92 | description: This may be used for SEO ().
93 | - name: category
94 | label: Categories
95 | type: tags
96 | - name: image
97 | label: Image
98 | type: image
99 | description: This may be used as a preview in social cards.
100 | - name: layout
101 | label: Layout
102 | type: string
103 | - name: body
104 | label: Body
105 | type: markdown
106 | autoresize: true
107 | posts:
108 | name: Posts
109 | fields:
110 | - name: published
111 | label: Published
112 | type: switch
113 | default: true
114 | - name: title
115 | label: Title
116 | type: string
117 | - name: date
118 | label: Date
119 | type: date
120 | - name: description
121 | label: Description
122 | type: string
123 | description: This may be used for SEO ().
124 | - name: category
125 | label: Categories
126 | type: tags
127 | - name: image
128 | label: Image
129 | type: image
130 | description: This may be used as a preview in social cards.
131 | - name: body
132 | label: Body
133 | type: markdown
134 | autoresize: true
135 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-good-communications.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Good communications
3 | category: Company
4 | ---
5 |
6 | **The most efficient communications are organized in a similar way**, may they be a [blog post](https://wiredcraft.com/blog/blogging-in-3-steps/), an email or an [issue on Github](https://wiredcraft.com/blog/how-we-write-our-github-issues/):
7 |
8 | - **Context**; don't assume people know what you're talking about. Frame the context of your message, this helps people understand where you're coming from.
9 | - **Teaser** (optional); once you've set up the context, it is preferable to quickly outline what the core issue or idea is. This is especially true if it requires a fair amount of details to be explained.
10 | - **Development**; stay concise and organized, for example using bullet points.
11 | - **Closing**; always close with possible solutions, next steps or your conclusion. You've done all that work, chances are that you have an opinion about it.
12 |
13 | Let me illustrate with a couple examples;
14 |
15 | - **Email to a client**; taking the assumption that we met Michael, the client, at a meetup and want to follow up on a potential lead.
16 |
17 | > Hey there Michael,
18 | >
19 | > Nice chatting with you at the meetup last week. I hope you enjoyed the talks; we're always looking for speakers so let me know if your colleagues would be interested.
20 | >
21 | > You mentioned a few things about your current project that you may need help with: we do native development (with both [Kotlin](https://wiredcraft.com/blog/android-apps-development-kotlin/) and [Swift](https://wiredcraft.com/blog/swift-languange-ios-development/) but had some really good results with [React Native](https://wiredcraft.com/blog/native-soundcloud-android-app/).
22 | >
23 | > I'd suggest that I pay you guys a visit with one of my mobile developers and have a little discussion with your mobile team to figure out which option is best.
24 | >
25 | > How about this Wednesday, 10:30 AM at your office? I'm sending you an invite, let me know if that works for you.
26 |
27 | I greet the client, remind him of the context of the discussion, detail our point of view, move on to list our options and close with the next step (you'll notice I'm also sending an invite without waiting for him to confirm his availability).
28 |
29 | - **GitHub issue**; [this issue](https://github.com/Wiredcraft/wiredcraft.github.io/issues/2474) is addressing the need for expanding the playbook to include a "Project" section.
30 |
31 | > As some of you may know, we've been gradually filling up the playbook. It's starting to take shape, but we're still missing a few important pieces. We really need the help of experts and seniors: the playbook is going to play a central role in helping
32 | >
33 | > The next section I'd like to add is "Project": we need a simple, no-nonsense guide to how we manage, lead and communicate around our projects. This will prove invaluable to our clients when we kick off a project as many of our ways of doing are disruptive to the enterprise folks we often work with.
34 | >
35 | > As usual, we'll start working on a simple outline and list of points we want to include. [Just fill things up on the Hackpad](https://wiredcraft.hackpad.com/Project-management-Playbook-J1SeS4YXyJU).
36 | >
37 | > I intend to have a very first draft online by this weekend, let's all have our notes in the Hackpad by tomorrow.
38 | >
39 | > /cc @JuhaS @makara @vincent923 @quentinberder @zbal
40 |
41 | I provide the context to this whole issue, from general to specific, then zero in on the core issue. I follow with the expected deliverable and a link to where we'll be gathering our notes. I close with a timeline and mention interested parties.
42 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-rules-and-benefits.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Rules & Benefits
3 | category: Employees
4 | sticky: true
5 | ---
6 |
7 | **We treat our colleagues as adults**.
8 |
9 | This means that sometimes team members bend the rules, but we expect them to do so in a respectful and mature way. Use company
10 | resources and privileges the same way you would use yours. Behave with others the same way you would with family members.
11 |
12 | Some of the main rules and benefits for our teammates1;
13 |
14 | - **We work between 9:30 AM and 6:30 PM** but allow for a lot of flexibility. We do recommend that you show before 11:00 AM
15 | though to make sure you have some overlap with those of us who start early. We're spread over China, Europe and sometimes
16 | the USA, so be mindful of other people's schedules.
17 | - **Days off & Holidays**; try and give us a heads up at least a week in advance so that we can plan for it (unless it's an emergency).
18 | We usually submit our request on the team's calendar and mention it to our colleagues and/or team leader for approval.
19 | - **Sick days & WFH (Work From Home)**; if you need (or want) to work from home for the day, simply give us a heads up on Slack/WeChat.
20 | Try and do so before work starts (9:30 AM) and make sure your team leader is in the loop.
21 | - **Remote work**; in some cases we allow colleagues to work remotely for a certain period of time (e.g. working from your
22 | hometown or another office for a few weeks). This is usually granted by your team leader on a per-case basis.
23 | - **Raises & Bonuses**; you can [read more about OKRs and performance reviews](http://playbook.wiredcraft.com/article/growth-performances-and-raises/) and
24 | how they relate to your compensation. We consider raises every 6 months, provide a 13th month at the end of the year and award cash
25 | or non-cash rewards/bonuses on a per-case basis.
26 | - **Transparency**. Disclose information that may be relevant to the team; personal relationships with clients and colleagues, past professional collaborations...
27 | - **Non-compete**; while you may have side projects going on, we ask that you do not work for direct competitors and that
28 | you avoid committing to projects that affect your performances at work.
29 | - **Privacy**; whether it's about our clients or your colleagues, we assume you'll be discrete about most things and especially careful with sensitive data
30 | (e.g. voter data for the elections of Myanmar).
31 | - **Reimbursements**; it's often more convenient for us to reimburse certain expenses (e.g. ticket for a conference) after your purchased it. Just
32 | make sure to check with your team leader first. If you can't cover the price, just create an issue in the appropriate repo (often the
33 | [team repo](https://github.com/Wiredcraft/team)) or follow the [reimbursement steps](http://playbook.wiredcraft.com/article/expenses-reimbursement/).
34 | - **Perks**; we have free lunches on Fridays, company off-sites, team building events, snacks at the office, ... Teams also have their
35 | own budgets to purchase useful resources (e.g. books, software licenses, media, gear). Ask your team leader.
36 |
37 | If you still don't have your answer, chances are that you're not the only one. Try one of the following;
38 |
39 | - [Ask a question](https://github.com/Wiredcraft/team/issues/new?body=Make+sure+to+select+the+question+label) and we'll try to add it to the
40 | playbook.
41 | - Ask your team leader or a member of the operations team. You can also drop a line to all leaders using your company email: [leadership@wiredcraft.com](mailto:leadership@wiredcraft.com.com).
42 | - Shoot an email to our CEO or reach out to him on Slack. If you want your feedback to be anonymous, just use the [anonymous feedback form](https://goo.gl/forms/xmTOMXDMrvFIDNud2).
43 |
44 | We can't satisfy every request, but we do listen, so don't hesitate to let us know what you think or need.
45 |
46 | 1: for a complete and accurate list of regulations, please refer to the official employee handbook.
47 |
--------------------------------------------------------------------------------
/_sass/partials/_base.scss:
--------------------------------------------------------------------------------
1 | @if index($partials, base) {
2 | html {
3 | @include breakpoint(mobile) {
4 | font-size: 57%;
5 | }
6 | @include breakpoint(tablet) {
7 | font-size: 59%;
8 | }
9 | @include breakpoint(desktop) {
10 | font-size: 62.5%;
11 | }
12 | }
13 |
14 | body {
15 | background: $background;
16 | color: $black;
17 | font-family: $body;
18 | @include font-size($regular);
19 | font-size: $regular + px; // Because of Chrome bug (see https://code.google.com/p/chromium/issues/detail?id=319623)
20 | font-weight: normal;
21 | line-height: 160%;
22 | }
23 |
24 | a {
25 | cursor: pointer;
26 | color: $blue;
27 | text-decoration: none;
28 | transition-property: color;
29 | transition-duration: $ease;
30 | &:hover {
31 | color: shade($blue, 10%);
32 | text-decoration: underline;
33 | }
34 | }
35 |
36 | h1,
37 | h2,
38 | h3,
39 | h4,
40 | h5,
41 | h6 {
42 | color: $black;
43 | font-family: $headline;
44 | font-weight: 700;
45 | line-height: 120%;
46 | margin: 0 0 $space;
47 | }
48 |
49 | h1 {
50 | @include font-size($headline-1);
51 | }
52 |
53 | h2 {
54 | @include font-size($headline-2);
55 | }
56 |
57 | h3,
58 | h4,
59 | h5,
60 | h6 {
61 | @include font-size($headline-3);
62 | }
63 |
64 | strong,
65 | b {
66 | font-weight: 700;
67 | }
68 |
69 | p,
70 | pre {
71 | margin: 0 0 $space;
72 | &.smaller {
73 | @include font-size($smaller);
74 | line-height: 160%;
75 | margin-bottom: $space/2;
76 | }
77 | }
78 |
79 | ul,
80 | ol {
81 | margin: 0 0 $space $space;
82 | padding: 0;
83 | li {
84 | margin: 0 0 $space/4;
85 | padding: 0;
86 | }
87 | ul,
88 | ol {
89 | margin-bottom: 0;
90 | li {
91 | margin: $space/4 0 0;
92 | }
93 | }
94 | }
95 |
96 | small {
97 | @include font-size($small);
98 | line-height: 160%;
99 | }
100 |
101 | blockquote {
102 | border-left: $space/4 solid $light;
103 | color: tint($black, 40%);
104 | margin: 0 $space $space;
105 | padding-left: $space;
106 | > *:last-child {
107 | margin-bottom: 0;
108 | }
109 | }
110 |
111 | img {
112 | max-width: 100%;
113 | }
114 |
115 | /* Code */
116 |
117 | code,
118 | .code {
119 | background: $light;
120 | border-radius: $radius;
121 | display: inline-block;
122 | font-family: $code;
123 | font-size: 85%;
124 | padding: 0 $space/4;
125 | }
126 |
127 | pre {
128 | code,
129 | .code {
130 | display: block;
131 | padding: $space/4 $space/2;
132 | white-space: pre-wrap;
133 | }
134 | }
135 |
136 | /* Tables */
137 |
138 | table {
139 | border: 0;
140 | border-collapse: collapse;
141 | margin: 0 0 $space;
142 | text-align: left;
143 | width: 100%;
144 | thead,
145 | tbody {
146 | th,
147 | td {
148 | border: 0;
149 | padding: $space/6 $space/4;
150 | }
151 | }
152 | thead {
153 | @include font-size($small);
154 | font-weight: bold;
155 | th {
156 | white-space: nowrap;
157 | }
158 | }
159 | tbody {
160 | tr {
161 | td,
162 | th {
163 | border-top: 1px solid $line-3;
164 | padding: $space/4;
165 | }
166 | }
167 | }
168 | }
169 |
170 | /* Icons */
171 |
172 | .icon {
173 | display: inline-block;
174 | vertical-align: middle;
175 | svg {
176 | display: block;
177 | fill: $grey;
178 | height: $space;
179 | transition-property: fill;
180 | transition-duration: $ease;
181 | vertical-align: middle;
182 | width: $space;
183 | }
184 | &.smaller {
185 | svg {
186 | height: 1.5*$space/2;
187 | width: 1.5*$space/2;
188 | }
189 | }
190 | &.small {
191 | svg {
192 | height: $space/2;
193 | width: $space/2;
194 | }
195 | }
196 | &.larger {
197 | svg {
198 | height: 1.5*$space;
199 | width: 1.5*$space;
200 | }
201 | }
202 | &.large {
203 | svg {
204 | height: 2*$space;
205 | width: 2*$space;
206 | }
207 | }
208 | }
209 | }
210 |
211 | a.icon {
212 | &:hover {
213 | svg {
214 | fill: $black;
215 | }
216 | }
217 | }
218 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-onboarding.md:
--------------------------------------------------------------------------------
1 | ---
2 | sticky: true
3 | title: Onboarding a new recruit
4 | category: Employees
5 | ---
6 |
7 | We try and **make people start their job on a Friday** for a few reasons;
8 |
9 | - The new team members gets a sense of accomplishment wrapping things up for the week with the rest of the team.
10 | - The team tends to be more relaxed and available for a chat than at the beginning of the week when things are kicking off.
11 | - Hires get to work for a day, get situated and have a full weekend to recover from the first impressions before attacking a full week.
12 |
13 | ## Before they arrive
14 |
15 | - **Gear**; make sure the employee is set with a proper chair, a laptop and a desk (you'd be surprised how easy it is to run out of space). We also usually prepare a tote bag with some swag (tshirts, hoodie, mug...) and a welcome card.
16 | - **Software**; make sure you create all accounts and send all invitations ahead of time:
17 | - **Google**: create the email account, update aliases if needed (e.g. marketing@wiredcraft.com) and invite the person to the relevant Google Drive folders (e.g. `WCL Business`).
18 | - **GitHub**: since we test candidates, the person should already have a GitHub account. Invite him to the proper [teams in the Wiredcraft org](https://github.com/orgs/Wiredcraft/teams).
19 | - **Slack**: Our main tool for smooth communication.
20 | - **LastPass**; we use it to save and share credentials across teams. Make sure the person is invited to [the relevant groups](https://lastpass.com/enterprise_usergroups.php).
21 | - **Other**; some people may require additional software, licenses or invitations. For example a Sketch license for designers or a [Streak](https://www.streak.com/) invite for sales people. Check with the team leader to figure out what tools may be required. Additionally, Chinese employees may need a VPN (we often pick [Astrill](https://www.astrill.com/)).
22 | - **Mentor & Leader**; make sure the team is clear on who is the new recruit's leader and who will mentor them through their first month. Typically, a leader is in charge of the team while a mentor is here to orient and train the recruit.
23 | - **Paperwork**; have the employment contract, IPA and NDA printed, reviewed and ready for them to sign.Check with the new hire if any additional paperwork is missing or help is needed.
24 | - **Probation period**; add the end of the probation period to the calendar (with a reminder) for both operations and the new employee's leader.
25 |
26 | ## On the first day
27 |
28 | - **Sign hard copies** of the employment contract, IPA and NDA.
29 | - **Intro to the team**. Walk the person through the office and introduce him to his colleagues. We often have an all-hands meeting on Friday, when we usually collectively welcome newcomers.
30 | - **Walk him to his desk** and make sure he is set (gear, software, swag, wifi access...).
31 | - **Point the employee at the playbook**, starting with this page, then the [company](http://playbook.wiredcraft.com/company/) & [employees](http://playbook.wiredcraft.com/employees/) sections. He can then read the other sections depending on his team and interest. Make sure you also [show him how to contribute to it](https://github.com/Wiredcraft/team#readme) (and why he should).
32 | - **First SCRUM**; this should help get the new recruit started with our process and is a good starting point to identify what he'll be working on the week after, explain responsibilities and orient to job duties.
33 | - **Friday team lunch** We love our Friday team lunches and it's a great opportunity for the new team member to meet everyone and find the first topics to talk about.
34 |
35 | ## The first week
36 |
37 | Focus on getting the new person started with our process and best practices ([collaborating through GitHub and Slack](http://playbook.wiredcraft.com/article/working-with-your-colleagues/), having a SCRUM every day, working on [clear communications](http://playbook.wiredcraft.com/article/good-communications/)...).
38 |
39 | During that first week, we usually get the employee to review his [recruitment issue](https://github.com/Wiredcraft/recruitment/issues) and collaborate to an issue in [the marketing repo](https://github.com/Wiredcraft/marketing) to write a blog post announcing him joining the team.
40 |
41 | ## The first month
42 |
43 | We schedule up to 10 short (15 to 20 minutes) "coffee breaks" between the new recruit and other team members (preferably outside of his team).
44 |
45 | This month (which coincides with the probation period in China) ends with the monthly One-on-One meeting where both, team member and team lead, can share their thoughts, feedback and set up next steps.
46 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-user-story.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: User story
3 | category: Projects
4 | ---
5 |
6 | When starting a project, it is important to define the Product backlog. This is commonly populated from the tasks covered by user stories. To write relevant user stories it is necessary to follow these point.
7 |
8 | 1. Understand your target users and outline them in **Personas**
9 | 2. Derive **Epics** from **Persona** goals
10 | 3. Break **Epics** into **User stories**
11 |
12 | Let's briefly outline each of the components.
13 |
14 | ## How to write Personas
15 |
16 | Supporting [goal-direct design](http://www.dubberly.com/articles/alan-cooper-and-the-goal-directed-design-process.html), and a key component for success, personas create tangible and reliable end users. It answers the question "*Who are we building things for?*" and follows:
17 |
18 | 1. **Profile**: detail who is this persona
19 | 2. **Roles**: define its roles, both in the professional and personal life
20 | 3. **Goals**: what is this persona trying to achieve
21 | 4. **Challenges**: what are the challenges this persona would be facing to achieve their goals
22 |
23 | For example:
24 |
25 | 1. *Jenny is a stay at home mum working part time at a day care centre. She is 33 years old and has a bachelor in social work. She is an avid user of online shopping website (Amazon, etc.) and social network about mode, food and travels (mainly Pinterest and Facebook).*
26 | 2. *She is a shopper.*
27 | 3. *She wants to do her shopping quickly and get all of the information about the products she is buying.*
28 | 4. *She is often not able to look for specific information about products to ensure they are safe for her children and day care kids. She also does not have a lot of time for herself and does not like to spend time on check out.*
29 |
30 | It is important to keep in mind:
31 |
32 | 1. They are **distinct**.
33 | 2. They are **recognizable**.
34 | 3. They are **complete** (not just a keyword).
35 | 4. They are **iterative** and can (and should) change over time.
36 |
37 | For more extensive explanations you can have a look at the [Smashing Magzine look at personas](https://www.smashingmagazine.com/2014/08/a-closer-look-at-personas-part-1/).
38 |
39 | ## What is an Epic?
40 |
41 | Broad ideas explaining product functionality independent from the details. Epics are not user stories, they only outline the high level functionality.
42 |
43 | For example:
44 |
45 | *"Provide option to shoppers to buy items online."*
46 |
47 | You can break down an Epic into several user stories, the inverse being not possible.
48 |
49 | ## How to write a user story
50 |
51 | User stories follow a simple 3-part format answering the fundamental questions (who, what and why):
52 |
53 | 1. **As a** [persona]
54 | 2. **I want to** [do something]
55 | 3. **so that I can** [achieve a goal]
56 |
57 | These user stories are validate by acceptance criteria which define the boundaries of a user story
58 |
59 | For example:
60 |
61 | * **User story**
62 | *"As a shopper, I want to add items to my cart so I can manage my order before I check out."*
63 |
64 | * **Acceptance criteria**
65 | * The number of items in the cart is displayed
66 | * The number of items in the cart is calculated with each item added, removed or updated
67 | * The current order amount is displayed
68 |
69 | Keep in mind that user stories and acceptance criteria are what we use to test and validate software; getting them right is key to a successful delivery.
70 |
71 | ## Dos and don'ts
72 |
73 | **Definitely do**:
74 |
75 | * Frame stories from an end user point of view, never from a manager or developer angle
76 | Good: As an admin user I want secure login so that I can use admin functions safely
77 | Bad: As a project manager I want better security so that the product is secure
78 | * Start big (Personas) and funnel down (user stories and acceptance criteria)
79 | * Make things visible to everyone.
80 | * Anybody can write the user stories and everybody should, your dev team should start to think in terms of user stories.
81 | * Follow the INVEST acronym (Independent, Negotiable, Valuable, Estimable, Small, Testable).
82 |
83 | And **do not**:
84 |
85 | * Write user stories for a user not a persona.
86 | * Describe how to implement. Stories should focus on what to implement.
87 | * Make non-descriptive, verbose or over-detailed stories, keep it brief.
88 | * Have multiple components in a user story, smaller stories are easier to define clearly and your team can estimate them more accurately.
89 | * Take user stories as a requirement, they are designed to support not define them. Raw requirements should be covered in acceptance criteria.
90 |
91 | For (far) more details and tips on this, we strongly recommend you have a look at [Best Agile user story from Alexander Cowan](http://www.alexandercowan.com/best-agile-user-story/).
92 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-using-github.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Using GitHub
3 | category: Development
4 | sticky: true
5 | ---
6 |
7 | **We use [GitHub for pretty much everything](https://wiredcraft.com/blog/github-for-everything/)** for mainly two reasons;
8 |
9 | 1. **It enforces the same workflow and discipline** on all aspects of our company, from code to sales.
10 | 1. **It reduces friction** for our (overwhelmingly technical) team to access and take part in anything we do (especially recruitment).
11 |
12 | ## A few gotchas
13 |
14 | - **Write proper issues & comments**; we've [written about it before](https://wiredcraft.com/blog/how-we-write-our-github-issues/). Always give context and clear next steps to your messages.
15 | - **Assignee, labels and milestones**; take the time to properly label your issues, assign them to somebody on the team (if you're not sure assign it to yourself or the SCRUM master) and tie it up to a milestone.
16 | - **Mentions**; we often end up a comment or issue with `/cc` followed by mentions of people we feel should be included in the thread.
17 | - **Meaningful commit messages**; avoid things like `updated stuff`. You want to make it easy for others to review your changes.
18 | - **Always have a README**; we always add a `README.md` file at the root of our repositories to explain what it is and potentially give further instructions (installation, deployment, todo list...).
19 | - **Check your notifications**; most likely the first thing you should do when you https://github.com/notifications/participating
20 |
21 | ## Our GitHub workflow
22 |
23 | Our worflow is a tad more complex than the [GitHub flow](https://guides.github.com/introduction/flow/), but not as much as [Atlassian's feature branch workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow).
24 |
25 | - "There are some work done to the master branch (or say the branch my branch/fork is based on) and I want to include the changes" or "There are some work done to the master branch and I got conflict with my PR now" - see QA
26 |
27 | ## Labels
28 |
29 | We use the [SANE Github labels formula](https://medium.com/@dave_lunny/sane-github-labels-c5d2e6004b63#.6zxtq53hf) helping to highlight the status, type and priority of each issue.
30 |
31 | **Development stage**
32 |
33 | These labels represent the current stage of development of the issue.
34 |
35 | Label | Description
36 | ------ | ------
37 |  | Issue is not yet acted on
38 |  | Issue is currently ongoing
39 |  | Issue is currently in review
40 |  | Issue is done
41 |  | Issue is ongoing QA by WCL
42 |  | Issue is ongoing QA by Clients
43 |
44 | **Type**
45 |
46 | These labels represent the current type of the issue.
47 |
48 | Label | Description
49 | ------ | ------
50 |  | The issue is a question about a feature
51 |  | The issue is a bug to an existing feature
52 |  | The issue is a task to be implemented
53 |  | The issue is an enhancement to an existing feature
54 |
55 | **Priority**
56 |
57 | These labels represent the current priority of the issue.
58 |
59 | Label | Description
60 | ------ | ------
61 |  | The issue is of low priority
62 |  | The issue is of medium priority
63 |  | The issue is of high priority
64 |  | The issue is of critical priority and should be resolved as soon as possible
65 |  | The issue is currently blocking the development of the features
66 |
--------------------------------------------------------------------------------
/_sass/partials/_layout.scss:
--------------------------------------------------------------------------------
1 | // Container
2 |
3 | .container {
4 | box-sizing: border-box;
5 | clear: both;
6 | @include clearfix;
7 | margin: 0 auto;
8 | max-width: $container;
9 | }
10 |
11 | // 2 columns
12 |
13 | .row {
14 | @include clearfix;
15 | clear: both;
16 | .left,
17 | .right {
18 | box-sizing: border-box;
19 | width: 50%;
20 | }
21 | .left {
22 | float: left;
23 | }
24 | .right {
25 | float: right;
26 | }
27 | }
28 |
29 | // Grid
30 |
31 | .grid,
32 | .grid-3 {
33 | @include breakpoint(mobile) {
34 | @include grid(1);
35 | }
36 | @include breakpoint(only_tablet) {
37 | @include grid(2);
38 | }
39 | @include breakpoint(desktop) {
40 | @include grid;
41 | }
42 | }
43 |
44 | .grid-4 {
45 | @include breakpoint(mobile) {
46 | @include grid(2);
47 | }
48 | @include breakpoint(only_tablet) {
49 | @include grid(3);
50 | }
51 | @include breakpoint(desktop) {
52 | @include grid(4);
53 | }
54 | }
55 |
56 | .grid-2 {
57 | @include breakpoint(mobile) {
58 | @include grid(1);
59 | }
60 | @include breakpoint(tablet) {
61 | @include grid(2);
62 | }
63 | }
64 |
65 | .grid,
66 | .grid-2,
67 | .grid-3,
68 | .grid-4 {
69 | clear: both;
70 | &.padded,
71 | &.padded-1 {
72 | margin: -$space/2;
73 | > * {
74 | padding: $space/2;
75 | }
76 | }
77 | &.padded-2 {
78 | margin: -$space;
79 | > * {
80 | padding: $space;
81 | }
82 | }
83 | }
84 |
85 |
86 | // Padding
87 |
88 | .padding-bottom-0 {
89 | padding-bottom: 0;
90 | }
91 | .padding-left-0 {
92 | padding-left: 0;
93 | }
94 | .padding-right-0 {
95 | padding-right: 0;
96 | }
97 | .padding-top-0 {
98 | padding-top: 0;
99 | }
100 |
101 | .padding-bottom-1-2 {
102 | padding-bottom: $space/2;
103 | }
104 | .padding-left-1-2 {
105 | padding-left: $space/2;
106 | }
107 | .padding-right-1-2 {
108 | padding-right: $space/2;
109 | }
110 | .padding-top-1-2 {
111 | padding-top: $space/2;
112 | }
113 |
114 | .padding-bottom {
115 | padding-bottom: $space;
116 | }
117 | .padding-left {
118 | padding-left: $space;
119 | }
120 | .padding-right {
121 | padding-right: $space;
122 | }
123 | .padding-top {
124 | padding-top: $space;
125 | }
126 |
127 | .padding-bottom-2 {
128 | @include breakpoint(mobile) { padding-bottom: $space; }
129 | @include breakpoint(tablet) { padding-bottom: 2*$space; }
130 | }
131 | .padding-left-2 {
132 | @include breakpoint(mobile) { padding-left: $space; }
133 | @include breakpoint(tablet) { padding-left: 2*$space; }
134 | }
135 | .padding-right-2 {
136 | @include breakpoint(mobile) { padding-right: $space; }
137 | @include breakpoint(tablet) { padding-right: 2*$space; }
138 | }
139 | .padding-top-2 {
140 | @include breakpoint(mobile) { padding-top: $space; }
141 | @include breakpoint(tablet) { padding-top: 2*$space; }
142 | }
143 |
144 | .padding-bottom-3 {
145 | @include breakpoint(mobile) { padding-bottom: 2*$space; }
146 | @include breakpoint(tablet) { padding-bottom: 4*$space; }
147 | }
148 | .padding-left-3 {
149 | @include breakpoint(mobile) { padding-left: 2*$space; }
150 | @include breakpoint(tablet) { padding-left: 4*$space; }
151 | }
152 | .padding-right-3 {
153 | @include breakpoint(mobile) { padding-right: 2*$space; }
154 | @include breakpoint(tablet) { padding-right: 4*$space; }
155 | }
156 | .padding-top-3 {
157 | @include breakpoint(mobile) { padding-top: 2*$space; }
158 | @include breakpoint(tablet) { padding-top: 4*$space; }
159 | }
160 |
161 | // Margin
162 |
163 | .margin-bottom-0 {
164 | margin-bottom: 0;
165 | }
166 | .margin-left-0 {
167 | margin-left: 0;
168 | }
169 | .margin-right-0 {
170 | margin-right: 0;
171 | }
172 | .margin-top-0 {
173 | margin-top: 0;
174 | }
175 |
176 | .margin-bottom-1-2 {
177 | margin-bottom: $space/2;
178 | }
179 | .margin-left-1-2 {
180 | margin-left: $space/2;
181 | }
182 | .margin-right-1-2 {
183 | margin-right: $space/2;
184 | }
185 | .margin-top-1-2 {
186 | margin-top: $space/2;
187 | }
188 |
189 | .margin-bottom {
190 | margin-bottom: $space;
191 | }
192 | .margin-left {
193 | margin-left: $space;
194 | }
195 | .margin-right {
196 | margin-right: $space;
197 | }
198 | .margin-top {
199 | margin-top: $space;
200 | }
201 |
202 | .margin-bottom-2 {
203 | @include breakpoint(mobile) { margin-bottom: $space; }
204 | @include breakpoint(tablet) { margin-bottom: 2*$space; }
205 | }
206 | .margin-left-2 {
207 | @include breakpoint(mobile) { margin-left: $space; }
208 | @include breakpoint(tablet) { margin-left: 2*$space; }
209 | }
210 | .margin-right-2 {
211 | @include breakpoint(mobile) { margin-right: $space; }
212 | @include breakpoint(tablet) { margin-right: 2*$space; }
213 | }
214 | .margin-top-2 {
215 | @include breakpoint(mobile) { margin-top: $space; }
216 | @include breakpoint(tablet) { margin-top: 2*$space; }
217 | }
218 |
219 | .margin-bottom-3 {
220 | @include breakpoint(mobile) { margin-bottom: 2*$space; }
221 | @include breakpoint(tablet) { margin-bottom: 4*$space; }
222 | }
223 | .margin-left-3 {
224 | @include breakpoint(mobile) { margin-left: 2*$space; }
225 | @include breakpoint(tablet) { margin-left: 4*$space; }
226 | }
227 | .margin-right-3 {
228 | @include breakpoint(mobile) { margin-right: 2*$space; }
229 | @include breakpoint(tablet) { margin-right: 4*$space; }
230 | }
231 | .margin-top-3 {
232 | @include breakpoint(mobile) { margin-top: 2*$space; }
233 | @include breakpoint(tablet) { margin-top: 4*$space; }
234 | }
235 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-how-to-prepare-a-proposal.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: How to prepare a proposal?
3 | category: Business
4 | ---
5 |
6 | Once we've identified an opportunity as "Qualified" (see *[How to track contacts & opportunities?](/business/2016/08/28/how-to-track-contacts-and-opportunities.html) and [Our sales workflow](http://playbook.wiredcraft.com/Business/our-sales-workflow.html)), we most likely need to produce a proposal to the client. This takes a few steps.
7 |
8 | ## Preparing the estimation
9 |
10 | 1. **Share all resources from the client**. You can save all the documents received up that point (e.g. wireframes, requirements, user interviews, strategy brief, etc.) into a Google Docs folder (`WCL Business › Projects › CLIENT_NAME › Resources`).
11 | 1. (Optional) **Send forms to client**
12 | 1. **Prepare the estimate and proposal documents** on Google Docs. You can copy the templates;
13 | - **[The estimate](https://docs.google.com/spreadsheets/d/1Rm5sLyNRPfyAHSn1fFT3pDI0DaQz4rrcC-iGvL5uYXg/edit#gid=0)** is a simple spreadsheet that allows us to list and describe the features/deliverables for the project. We then associate a work load in days to each item, which gives us the cost. More on that below.
14 | - **[The proposal](https://docs.google.com/document/d/1G-85aBaMfkWUFGV8QSgKLYD-jpbOBJy6EO9cSdBHvN4/edit#heading=h.gunwswcnh42l)** is a much larger document that we deliver to the client. While it includes the estimate information, it also gives an overview of the company, team, strategy, portfolio...
15 | 1. **Create a GitHub issue** that you'll assign to the person on the team who will prepare the estimate. To make this easy on him/her to it done, you should give as much context to it ([example of this](https://github.com/Wiredcraft/sales/issues/59));
16 | - Context: what is the project about
17 | - Customer: who is the customer
18 | - Budget: what is the budget available for it (do not hesitate to be upfront and ask)
19 | - Timeline: any relevant (e.g. expected launch date, any external event, etc.)
20 | - Assets: add any relevant assets (e.g. RFP, data diagram, etc.)
21 | Note that it is important to label your issue properly (most likely to start, Stage: Lead and Status: Backlog).
22 | 1. **Assign the issue to the proper person**. Depending on the nature of the project, you may want to send this to a project manager, a developer or a designer. When in doubt, ask on Slack who can tackle it,
23 | 1. **Outline the next steps**. To ensure the estimation is properly followed through, make sure to outline the next steps,
24 | 1. **Add the key dates to the sales calendar** and **book time of relevant team members**. You want to make sure we send notice of intent, questions and estimates in due time. You also want to time box the efforts of your team working on the proposal,
25 |
26 | You'll notice that the way we go at estimating projects is pretty simple. A few things about it;
27 |
28 | - **There are recurrent items in most projects**. Things like QA, documentation, testing, project launch, ...
29 | - **The hard part is to identify what the features are and describe them concisely**. Once this is done, estimating the work load is pretty easy,
30 | - **We estimate in man/days but don't get hung up on the details**. In the end, this process is mostly there to:
31 | - Ensure we are not underestimating certain aspects of the project (*aka* "losing money"),
32 | - Have a simple medium to communicate our assumptions to the client.
33 | - **We often end up tweaking the budget a lot** either to fit the client's resources or our gut feeling with regards to overall difficulty of the project. Projects always have a lot of imponderables, estimates are all about finding a compromise between what the client can afford and what we feel comfortable getting engaged for.
34 | - **Timing is important** you should go fast to answer but not rushing and omitting issues. You should submit the strategy under 5 days maximum (for normal contracts and after last meeting with client)
35 |
36 | Make sure to have a look at the [Product Development Solutions](https://docs.google.com/spreadsheets/d/14_Jmn6jSlexTmvThf2B8RLX05q-zAsgxVQeNGwDfXqs/edit#gid=1144347627).
37 |
38 | ## Finalize proposal
39 |
40 | Once the estimate is done, you should finalize the proposal you'll send over to the client;
41 |
42 | 1. **Drop the budget** from the estimate into the "Budget" section. In some cases, it is better to split this section in several sub-budgets for each main milestone/deliverable and give an "Overview" budget.
43 | 1. **Fill in the details; title, context, etc.**. These should mostly be well understood at that stage as you've probably done most of the work when you created the GitHub issue.
44 | 1. **Add a strategy**. This is often a crucial part of the proposal; you may need to refer to existing resources (e.g. [How we design products](https://wiredcraft.com/blog/how-we-design-products/)) and/or work with the person who prepared the estimate to get . Some of our larger projects (e.g. [Myanmar elections](https://drive.google.com/a/wiredcraft.com/file/d/0B1cjUQNjdmJMamxIRWRLekk2eVU/view)) feature an extensive strategy with a lot of details and schemas detailing the architecture, technical stack, user flow, etc.
45 | 1. (Optional) **"The Wiredcraft advantage"**; we sometimes include a section that explains why our team is a particularly good fit. More often than not, we mention projects that are very similar or demonstrate skills crucial to the project.
46 | 1. **Share it with the client**; once you've double-checked everything with the rest of the team, you can share it as a PDF with the client or (alternatively as a view-only Google Doc).
47 |
--------------------------------------------------------------------------------
/_posts/2018-09-01-software-development-life-cycle.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Software Development Life Cycle (SDLC)
3 | category: Development
4 | sticky: true
5 | ---
6 |
7 | A high level outline of it would be as follow:
8 |
9 | 
10 |
11 | The cycle is as follow.
12 |
13 | ### Product management phase *(ongoing process)*
14 |
15 | * **Define Requirements** - Define the requirements for the iteration based on the product backlog, sprint backlog, customer and stakeholder feedback.
16 | * **Design and Strategy** - Design UI/UX based on defined requirements and form an initial technical strategy/plan for the project. This step also includes writing user stories for the features.
17 |
18 |
19 | ### Software Development Lifecycle *(recurring loop)*
20 |
21 | * **Milestone plan** - Pick the top priority features that are part of this phase of the project and plan them.
22 | * **Development** - Develop software based on defined requirements locally and testing in development environments
23 | * **QA (Quality Assurance) testing** - Continuous internal and external testing based on the user stories and design mockups.
24 | * **Release to staging** - Release stable features to staging server
25 | * **Performance or Security testing** - For large releases we will perform performance testing and security testing, usually in the staging environment.
26 | * **UAT (User Acceptance Testing) and Validation Testing** - UAT often onvolves testing by the people from the intended audience and recording and correcting of any defects which are discovered. Validation testing can be done by the project stakeholders who are familiar with the project scope to ensure product meets the requirements.
27 | * **Release** - Integrate and deliver the working iteration into production
28 | * **Data analysis** - Review the available data points from production environments to analyze the effect of the release (see more in post release section below).
29 |
30 | Throughout the cycle the following is continuously performed:
31 |
32 | * **Unit testings** - Test the integrated unit to ensure it is producing expected output against given input.
33 | We are currently using the following:
34 | * React - [Jest](https://facebook.github.io/jest/)
35 | * WeChat - [Jest](https://facebook.github.io/jest/)
36 | * Nodejs - [Mocha](https://mochajs.org/)
37 | * **Code coverage** - To oultine code not covered by the test suite.
38 | We are currently using the following:
39 | * [Coveralls.io](https://coveralls.io/)
40 | * **CI (Continuous Integration)** - Test if a group of components are combined to produce output.
41 | We are currently using the following:
42 | * [TravisCI](https://travis-ci.com/)
43 | * **CD (Continuous Delivery)** - Automated release process.
44 | We are currently using the following:
45 | * [Pipeline](https://github.com/Wiredcraft/pipelines)
46 | * **Performance** - We test the behavior of the system under heavy load to identify bottlenecks and validate stability.
47 | We are currently using the following:
48 | * [locust.io](https://locust.io/)
49 |
50 | ### Shipping
51 |
52 | * **Tag and Changelog** - Outlining changes for release and providing a link to a specific version of the code.
53 | * **Documentation & updates** - Anything relevant to the released version such as (list non exhaustive):
54 | * Architecture changes
55 | * New requirements for deployment
56 | * Sequence diagrams
57 | * API documentation
58 | * **Internal & external sign off** - Ensure internal and external kickoff for release.
59 |
60 | On top of this, the following are taking place before major production releases:
61 |
62 | * **Static code security scans** - To check everything “under the hood” without actually executing the code to detect basic flaws and code sanity.
63 | * **Vulnerability scans** - Scan the apps for security vulnerability such as Cross-site scripting, SQL Injection and insecure server configuration.
64 | * **Regression testing** - Test the new version to ensure that any change or addition hasn't broken any existing functionality.
65 |
66 | For major releases, and to ensure impartiality of the results, we leverage the client’s internal IT team or external vendor (e.g. [Cigital](https://www.cigital.com)).
67 |
68 | Note:
69 |
70 | * In practice there are multiple smaller loops and feedback channels in each step to allow reacting faster to new circumstances and requirements.
71 |
72 |
73 | ## Post release
74 |
75 | Post release we gather, collect and analyze various sources, work it into the requirements of the next iteration or react to it in real time.
76 |
77 |
78 | * **Customer and stakeholder feedback** - Collect feedback from users and product stakeholders.
79 | * **Analytics** - We collect and report on user behavior (e.g. [Google Analytics](https://analytics.google.com/analytics/web/), [Google Data Studio](https://datastudio.google.com/), [Tableau](https://www.tableau.com/), etc.)
80 | * **User errors** - Automated reports and monitoring on user errors and crashes (e.g. [Fabric.io](http://fabric.io/))
81 | * **System metrics** - Processing system level time-series data and infrastructure monitoring (e.g. [TICK stack](https://www.influxdata.com/time-series-platform/))
82 | * **Log pipeline** - Log collection and analysis (e.g. [ELK stack](https://www.elastic.co/elk-stack))
83 |
84 | Additionally for mobile apps.
85 |
86 | * **User reviews** - Reviewing rating and comments on major stores (e.g. [AppFollow](https://appfollow.io/) for Google Play and App Store)
87 |
88 |
89 |
90 | ### Recommended reads
91 |
92 | * [The software development lifecycle](https://medium.com/@shipitgood/the-software-development-lifecycle-d90f4af8514f)
93 | * [The Four Levels of Software Testing](https://www.seguetech.com/the-four-levels-of-software-testing/)
94 | * [Understanding the Agile Software Development Lifecycle and Process Workflow](https://www.smartsheet.com/understanding-agile-software-development-lifecycle-and-process-workflow)
95 |
96 |
--------------------------------------------------------------------------------
/_sass/vendors/_normalize.scss:
--------------------------------------------------------------------------------
1 | /*! normalize.css v8.0.0 | MIT License | github.com/necolas/normalize.css */
2 |
3 | /* Document
4 | ========================================================================== */
5 |
6 | /**
7 | * 1. Correct the line height in all browsers.
8 | * 2. Prevent adjustments of font size after orientation changes in iOS.
9 | */
10 |
11 | html {
12 | line-height: 1.15; /* 1 */
13 | -webkit-text-size-adjust: 100%; /* 2 */
14 | }
15 |
16 | /* Sections
17 | ========================================================================== */
18 |
19 | /**
20 | * Remove the margin in all browsers.
21 | */
22 |
23 | body {
24 | margin: 0;
25 | }
26 |
27 | /**
28 | * Correct the font size and margin on `h1` elements within `section` and
29 | * `article` contexts in Chrome, Firefox, and Safari.
30 | */
31 |
32 | h1 {
33 | font-size: 2em;
34 | margin: 0.67em 0;
35 | }
36 |
37 | /* Grouping content
38 | ========================================================================== */
39 |
40 | /**
41 | * 1. Add the correct box sizing in Firefox.
42 | * 2. Show the overflow in Edge and IE.
43 | */
44 |
45 | hr {
46 | box-sizing: content-box; /* 1 */
47 | height: 0; /* 1 */
48 | overflow: visible; /* 2 */
49 | }
50 |
51 | /**
52 | * 1. Correct the inheritance and scaling of font size in all browsers.
53 | * 2. Correct the odd `em` font sizing in all browsers.
54 | */
55 |
56 | pre {
57 | font-family: monospace, monospace; /* 1 */
58 | font-size: 1em; /* 2 */
59 | }
60 |
61 | /* Text-level semantics
62 | ========================================================================== */
63 |
64 | /**
65 | * Remove the gray background on active links in IE 10.
66 | */
67 |
68 | a {
69 | background-color: transparent;
70 | }
71 |
72 | /**
73 | * 1. Remove the bottom border in Chrome 57-
74 | * 2. Add the correct text decoration in Chrome, Edge, IE, Opera, and Safari.
75 | */
76 |
77 | abbr[title] {
78 | border-bottom: none; /* 1 */
79 | text-decoration: underline; /* 2 */
80 | text-decoration: underline dotted; /* 2 */
81 | }
82 |
83 | /**
84 | * Add the correct font weight in Chrome, Edge, and Safari.
85 | */
86 |
87 | b,
88 | strong {
89 | font-weight: bolder;
90 | }
91 |
92 | /**
93 | * 1. Correct the inheritance and scaling of font size in all browsers.
94 | * 2. Correct the odd `em` font sizing in all browsers.
95 | */
96 |
97 | code,
98 | kbd,
99 | samp {
100 | font-family: monospace, monospace; /* 1 */
101 | font-size: 1em; /* 2 */
102 | }
103 |
104 | /**
105 | * Add the correct font size in all browsers.
106 | */
107 |
108 | small {
109 | font-size: 80%;
110 | }
111 |
112 | /**
113 | * Prevent `sub` and `sup` elements from affecting the line height in
114 | * all browsers.
115 | */
116 |
117 | sub,
118 | sup {
119 | font-size: 75%;
120 | line-height: 0;
121 | position: relative;
122 | vertical-align: baseline;
123 | }
124 |
125 | sub {
126 | bottom: -0.25em;
127 | }
128 |
129 | sup {
130 | top: -0.5em;
131 | }
132 |
133 | /* Embedded content
134 | ========================================================================== */
135 |
136 | /**
137 | * Remove the border on images inside links in IE 10.
138 | */
139 |
140 | img {
141 | border-style: none;
142 | }
143 |
144 | /* Forms
145 | ========================================================================== */
146 |
147 | /**
148 | * 1. Change the font styles in all browsers.
149 | * 2. Remove the margin in Firefox and Safari.
150 | */
151 |
152 | button,
153 | input,
154 | optgroup,
155 | select,
156 | textarea {
157 | font-family: inherit; /* 1 */
158 | font-size: 100%; /* 1 */
159 | line-height: 1.15; /* 1 */
160 | margin: 0; /* 2 */
161 | }
162 |
163 | /**
164 | * Show the overflow in IE.
165 | * 1. Show the overflow in Edge.
166 | */
167 |
168 | button,
169 | input { /* 1 */
170 | overflow: visible;
171 | }
172 |
173 | /**
174 | * Remove the inheritance of text transform in Edge, Firefox, and IE.
175 | * 1. Remove the inheritance of text transform in Firefox.
176 | */
177 |
178 | button,
179 | select { /* 1 */
180 | text-transform: none;
181 | }
182 |
183 | /**
184 | * Correct the inability to style clickable types in iOS and Safari.
185 | */
186 |
187 | button,
188 | [type="button"],
189 | [type="reset"],
190 | [type="submit"] {
191 | -webkit-appearance: button;
192 | }
193 |
194 | /**
195 | * Remove the inner border and padding in Firefox.
196 | */
197 |
198 | button::-moz-focus-inner,
199 | [type="button"]::-moz-focus-inner,
200 | [type="reset"]::-moz-focus-inner,
201 | [type="submit"]::-moz-focus-inner {
202 | border-style: none;
203 | padding: 0;
204 | }
205 |
206 | /**
207 | * Restore the focus styles unset by the previous rule.
208 | */
209 |
210 | button:-moz-focusring,
211 | [type="button"]:-moz-focusring,
212 | [type="reset"]:-moz-focusring,
213 | [type="submit"]:-moz-focusring {
214 | outline: 1px dotted ButtonText;
215 | }
216 |
217 | /**
218 | * Correct the padding in Firefox.
219 | */
220 |
221 | fieldset {
222 | padding: 0.35em 0.75em 0.625em;
223 | }
224 |
225 | /**
226 | * 1. Correct the text wrapping in Edge and IE.
227 | * 2. Correct the color inheritance from `fieldset` elements in IE.
228 | * 3. Remove the padding so developers are not caught out when they zero out
229 | * `fieldset` elements in all browsers.
230 | */
231 |
232 | legend {
233 | box-sizing: border-box; /* 1 */
234 | color: inherit; /* 2 */
235 | display: table; /* 1 */
236 | max-width: 100%; /* 1 */
237 | padding: 0; /* 3 */
238 | white-space: normal; /* 1 */
239 | }
240 |
241 | /**
242 | * Add the correct vertical alignment in Chrome, Firefox, and Opera.
243 | */
244 |
245 | progress {
246 | vertical-align: baseline;
247 | }
248 |
249 | /**
250 | * Remove the default vertical scrollbar in IE 10+.
251 | */
252 |
253 | textarea {
254 | overflow: auto;
255 | }
256 |
257 | /**
258 | * 1. Add the correct box sizing in IE 10.
259 | * 2. Remove the padding in IE 10.
260 | */
261 |
262 | [type="checkbox"],
263 | [type="radio"] {
264 | box-sizing: border-box; /* 1 */
265 | padding: 0; /* 2 */
266 | }
267 |
268 | /**
269 | * Correct the cursor style of increment and decrement buttons in Chrome.
270 | */
271 |
272 | [type="number"]::-webkit-inner-spin-button,
273 | [type="number"]::-webkit-outer-spin-button {
274 | height: auto;
275 | }
276 |
277 | /**
278 | * 1. Correct the odd appearance in Chrome and Safari.
279 | * 2. Correct the outline style in Safari.
280 | */
281 |
282 | [type="search"] {
283 | -webkit-appearance: textfield; /* 1 */
284 | outline-offset: -2px; /* 2 */
285 | }
286 |
287 | /**
288 | * Remove the inner padding in Chrome and Safari on macOS.
289 | */
290 |
291 | [type="search"]::-webkit-search-decoration {
292 | -webkit-appearance: none;
293 | }
294 |
295 | /**
296 | * 1. Correct the inability to style clickable types in iOS and Safari.
297 | * 2. Change font properties to `inherit` in Safari.
298 | */
299 |
300 | ::-webkit-file-upload-button {
301 | -webkit-appearance: button; /* 1 */
302 | font: inherit; /* 2 */
303 | }
304 |
305 | /* Interactive
306 | ========================================================================== */
307 |
308 | /*
309 | * Add the correct display in Edge, IE 10+, and Firefox.
310 | */
311 |
312 | details {
313 | display: block;
314 | }
315 |
316 | /*
317 | * Add the correct display in all browsers.
318 | */
319 |
320 | summary {
321 | display: list-item;
322 | }
323 |
324 | /* Misc
325 | ========================================================================== */
326 |
327 | /**
328 | * Add the correct display in IE 10+.
329 | */
330 |
331 | template {
332 | display: none;
333 | }
334 |
335 | /**
336 | * Add the correct display in IE 10.
337 | */
338 |
339 | [hidden] {
340 | display: none;
341 | }
342 |
--------------------------------------------------------------------------------